shanecoughlan
Beta member
- Messages
- 0
There is a gross inequality in the distribution of empowering Information and Communication Technology (ICT). Access to productivity and communication solutions is currently the domain of the richest one sixth of the world, with the remaining five sixths remaining resolutely disenfranchised with regards personal computing, mobile communication, and instant processing of information. This is the 'Digital Divide,' an unnecessarily damaging situation where the people who most need productivity solutions are unable to obtain them. In effect, the vast majority of the human race is condemned to prolonged poverty and inefficient economic, political and social solutions due to neglect and a lack of effort with regards sharing technology.
There are some positive initiatives underway to introduce modern ICT technologies into developing nations. Perhaps the most successful are the campaigns to recycle mobile phones into under-privileged nations, thus giving disparate populations access to rudimentary voice communication solutions. More ambitious projects exist too, ranging from serious efforts to recycle old personal computers through to the $100 laptop being advocated by Nicholas Negroponte from MIT labs.
This paper wishes to make a further contribution to positive suggestions for ICT empowerment and a reduction in the Digital Divide. The basic premise is that it might be possible to utilise and extend existing technologies to provide functional systems for ICT in developing nations. The method for incremental empowerment utilises a technology that is already deployed in developing nations: the mobile phone.
Mobile phones provide two essential elements of ICT infrastructure. They are connected to a digital network, and they have processing capacity. Newer telephones are capable of running applications, and have rudimentary support for email and Internet communication. Apart from having three inherent design limitations regarding small input devices, limited screen size and limited memory, they provide an excellent ICT front-end.
We will address the limitations of mobile devices, firstly examining the critical issue of hardware. Mobile phones don't have keyboards that are suitable for typing, and they don't have screens suitable for running productivity applications.
There is a preexisting solution for enabling the connection of keyboards to mobile phones. It is called a USB port, and many mobile phones already have these ports for things like PictBridge (a way to print directly from phone to printer). A simple USB connection and a little bit of tweaking of the internal hardware design of the mobile phone would allow a user to connect a standard PC keyboard to the device.
The second hardware issue is a little bit more difficult to resolve. The limited screen size of mobile phones is an engineering reality and cannot be avoided. To increase screen real estate requires either increasing the physical size of the mobile phones, or implementing an extension to the mobile phones that will allow images to be output to external devices such as television sets.
The first option is not viable, as increasing the size of the mobile phones would reduce their utility as portable telephones, and the larger physical screen size would reduce battery life exponentially. In effect, they would no longer be mobile phones. They would be small notebook computers with ring tones.
The second option is viable, but requires a certain level of commitment from manufacturers to introduce an output port on all new mobile phones. The port would be designed to work in conjunction with a special cable to allow connection from the mobile phone to the aerial input on a television set. This would provide the mobile phone with a display area of 720x480 on NTSC televisions and 720x576 on PAL televisions.
This mobile phone output port would provide little utility in developed nations outside of slide-shows and video screenings, but would act as an essential hardware extension for turning modern mobiles into fully-fledged ICT solutions in developing nations. People in developing nations already have access to television sets, and increasingly they have access to mobile phones.
With a standard PC keyboard, a mobile phone, a television set and cable to connect the phone to the TV set, a complete physical networked ICT system would exist and depend only on the software to power it.
We must now address the second key limitation of mobile phones. Mobile phones are low power devices designed for relatively limited computational tasks. They have limited memory, limited ability to process complex tasks, and a finite battery life. Any attempt to extend a mobile phone's computing remit needs to take these factors into account.
This paper's key suggestion is that a carefully designed series of computational tasks can be accomplished by the intelligent use of preexisting mobile phone technology and dynamically loaded software modules. It sounds complex, but it is really just about intelligent use of things that already exist, or can be easily created.
In traditional computing we think of applications as big programs that do something. Microsoft Word is a big application that runs and allows you to create a document. It can spell check the document, it can print the document. It can even help you put a movie in your document. It does a lot, but it's big. It uses a lot of space on your computer and it takes up a lot of memory and processing power. Precisely because Microsoft Word has a lot of capabilities, it requires a lot of resources.
Mobile phones simply don't have a lot of memory or processing power, and therefore they cannot run an application like Microsoft Word. To get a mobile phone to run an application means rethinking how we make an application. Instead of thinking about an application as a completed concept (a big tool that allow people to edit documents), we need to think of an application as lots of tiny little 'services' that are called to do something when they are needed. When the services are not needed, they just switch themselves off.
If we are going to be technical about it, we would say that services need to be incrementally loaded modular components designed to accomplish certain tasks without overloading the processing or memory capacity of the mobile phone.
Mobile phones already do this to an extent, especially in their support for lots of different types of communication. Modern mobile phones can send email (we call this POP and SMTP support), they can access the Internet (with what is called a network stack) and they can save information to little memory cards. Mobile phones don't do all of these things at once. In fact, to preserve memory, processing power and battery life, mobile phones usually do one thing at a time. Therefore mobile phones already have a lot of services that can be called when they are needed.
We are going to extend that concept to office productivity applications.
A productivity application is actually a lot of different services that used by the person trying to be productive. Some of these functions are critical, but most of them are what might be termed optional. You don't need these services to be productive, but you might want to be able to call them. For example, you don't need a spell checker to type a letter, but you might want to use one after you have drafted the letter. The spell checker is a service, and we don't need to load it into memory until you specifically say “check my spelling now.”
If you reconceptualise an application as different services you can quickly create a map of how resource usage can be minimalised. Certain services such as drawing text (text rendering), understanding user input (keyboard driver) and outputting images to the screen (display driver) must be loaded at all times, but others services for saving documents, sending emails or checking grammar can load dynamically according to task requirements. An example of how this works is below:
Word Processor/Email client
|
Text and HTML render engine
Dictionary service (inactive)
Saving/sending service (inactive)
|
Java Virtual Machine
|
Mobile OS
Mobile SMTP/Network stack (inactive)
This looks awfully complex, but it's not really.
At the top of the pile there is a 'Word Processor/Email client,' which is a hypothetical application front-end. That's what the user of the mobile phone sees. It looks like a word processor that can also send emails. Below that there is a 'Text and HTML render engine,' which draws the text on the screen. Beside this there are other things like a 'Dictionary service' for spell checking and a 'Saving/sending service' that can help the end user save or email a document. These all run on a 'Java Virtual Machine,' which is an engine to run applications. This is already on most mobile phones, and it can be understood as a really powerful way to run programs on any phone or computer. At the bottom there is the 'Mobile OS,' (Operating System) which is the heart of the phone. It controls the basic functions of the phone, and stops and starts things like the Java Virtual Machine. The 'Mobile OS' works with the 'Mobile SMTP/Network stack' to allow communication on the Internet or through telephone calls.
Let's reverse direction, and go through that again.
At the very bottom of the example there is a preexisting Mobile OS running a simple Java Virtual Machine (Java VM). The mobile has a SMTP/Network stack which is inactive, but can be called by the Mobile OS when required. This means that the network stack is consuming no resources when it's not needed.
The Java VM is running a lightweight Text and HTML render engine. This can render (show) text and standard compliant (X)HTML. Given current standards, perhaps 'UTF-8' (text standard) support and 'XHTML 1.0 transitional' (web language standard) support would make the most sense. Because resources are limited, even this render engine might benefit from being modular. This would mean loading support for common rendering tasks into memory by default, but leaving out special sub-services that support unusual XHTML tags or the like. The render engine could accomplish this by only loading all rendering sections when it comes across an unknown XHTML tag.
Beside the Text and HTML rendering engine there are inactive services. These could include a dictionary service and a lightweight service for saving or sending the completed text and HTML files. These services would be wholly inactive until called, and when called might assume temporary control of the environment (pausing the user front end) to accomplish their task without memory or processor overload. This would have the advantage of minimising memory usage with the disadvantage of only allowing one task to be accomplished at a time.
The dictionary service is a fairly straightforward concept. A dictionary file would exist on the mobile phone, and so would a service to take the user input (what is written on the screen) and compare it to the dictionary file. The saving/sending service is more abstract. This would be a service designed to save the user input from the screen (the Random Access Memory; RAM) to the main memory (like a MMC card), or to take the user input from the screen and send it as an email through the SMTP/Network stack.
The top of the modular application framework is the application front-end. This would be a simple window with basic menu items (used to call the other modular services), and a canvas for user input. In most cases input would be textual (word processing, email, spreadsheet, database), but there is room for graphical input as well. It all depends on what services are running or can be called by the application front-end.
The application front-end would actually be pretty light, as all application 'actions' would actually be separate modules loaded dynamically as needed. The text and HTML render engine and any (option) graphic rendering engines would also exist below the front-end, providing essential services to all aspects of the user interface without requiring a large overhead.
By having a well designed modular framework such as this it should be possible to give the appearance of a complete network aware office suite using the limited resources available in a mobile phone. Best of all, because almost all services would be shared easily and openly, application development time would be dramatically reduced. Once primary services like the text and HTML render engine existed, creating a new application would largely consist of making a front-end and linking it to the services underneath. Adding a new service (like video decoding or a random number generator) would provide new functionality for all front-ends with a minor update.
It's all about cooperation, and sharing. The mobile office would actually not be an application or an application suite running on a telephone. It would be loads of little services calling each other when needed, and disappearing into the background when not required. At least in theory this could allow for quite complex ICT tasks to be accomplished with a very modest computational device.
All we need to build are mobile phones with two ports, some simple cables, and some smart software services. We are talking about a complete networked productivity solution. It's not a solution for the developed world, but in Africa, South Asia and Latin America it could make a massive difference. New phones for the rich, recycled phones for the poor. The devices would spread along existing channels, and supplement existing technology without requiring massive investment, training or logistics. Existing networks would carry the signals. Existing knowledge would empower the users.
$100 laptops are a great idea for the future, but people have mobile phones and TVs now. With a little effort we could really make that count for something, and take another step towards closing the Digital Divide.
This article is licensed under a Creative Commons Attribution 2.5 License (http://creativecommons.org/licenses/by/2.5/)
There are some positive initiatives underway to introduce modern ICT technologies into developing nations. Perhaps the most successful are the campaigns to recycle mobile phones into under-privileged nations, thus giving disparate populations access to rudimentary voice communication solutions. More ambitious projects exist too, ranging from serious efforts to recycle old personal computers through to the $100 laptop being advocated by Nicholas Negroponte from MIT labs.
This paper wishes to make a further contribution to positive suggestions for ICT empowerment and a reduction in the Digital Divide. The basic premise is that it might be possible to utilise and extend existing technologies to provide functional systems for ICT in developing nations. The method for incremental empowerment utilises a technology that is already deployed in developing nations: the mobile phone.
Mobile phones provide two essential elements of ICT infrastructure. They are connected to a digital network, and they have processing capacity. Newer telephones are capable of running applications, and have rudimentary support for email and Internet communication. Apart from having three inherent design limitations regarding small input devices, limited screen size and limited memory, they provide an excellent ICT front-end.
We will address the limitations of mobile devices, firstly examining the critical issue of hardware. Mobile phones don't have keyboards that are suitable for typing, and they don't have screens suitable for running productivity applications.
There is a preexisting solution for enabling the connection of keyboards to mobile phones. It is called a USB port, and many mobile phones already have these ports for things like PictBridge (a way to print directly from phone to printer). A simple USB connection and a little bit of tweaking of the internal hardware design of the mobile phone would allow a user to connect a standard PC keyboard to the device.
The second hardware issue is a little bit more difficult to resolve. The limited screen size of mobile phones is an engineering reality and cannot be avoided. To increase screen real estate requires either increasing the physical size of the mobile phones, or implementing an extension to the mobile phones that will allow images to be output to external devices such as television sets.
The first option is not viable, as increasing the size of the mobile phones would reduce their utility as portable telephones, and the larger physical screen size would reduce battery life exponentially. In effect, they would no longer be mobile phones. They would be small notebook computers with ring tones.
The second option is viable, but requires a certain level of commitment from manufacturers to introduce an output port on all new mobile phones. The port would be designed to work in conjunction with a special cable to allow connection from the mobile phone to the aerial input on a television set. This would provide the mobile phone with a display area of 720x480 on NTSC televisions and 720x576 on PAL televisions.
This mobile phone output port would provide little utility in developed nations outside of slide-shows and video screenings, but would act as an essential hardware extension for turning modern mobiles into fully-fledged ICT solutions in developing nations. People in developing nations already have access to television sets, and increasingly they have access to mobile phones.
With a standard PC keyboard, a mobile phone, a television set and cable to connect the phone to the TV set, a complete physical networked ICT system would exist and depend only on the software to power it.
We must now address the second key limitation of mobile phones. Mobile phones are low power devices designed for relatively limited computational tasks. They have limited memory, limited ability to process complex tasks, and a finite battery life. Any attempt to extend a mobile phone's computing remit needs to take these factors into account.
This paper's key suggestion is that a carefully designed series of computational tasks can be accomplished by the intelligent use of preexisting mobile phone technology and dynamically loaded software modules. It sounds complex, but it is really just about intelligent use of things that already exist, or can be easily created.
In traditional computing we think of applications as big programs that do something. Microsoft Word is a big application that runs and allows you to create a document. It can spell check the document, it can print the document. It can even help you put a movie in your document. It does a lot, but it's big. It uses a lot of space on your computer and it takes up a lot of memory and processing power. Precisely because Microsoft Word has a lot of capabilities, it requires a lot of resources.
Mobile phones simply don't have a lot of memory or processing power, and therefore they cannot run an application like Microsoft Word. To get a mobile phone to run an application means rethinking how we make an application. Instead of thinking about an application as a completed concept (a big tool that allow people to edit documents), we need to think of an application as lots of tiny little 'services' that are called to do something when they are needed. When the services are not needed, they just switch themselves off.
If we are going to be technical about it, we would say that services need to be incrementally loaded modular components designed to accomplish certain tasks without overloading the processing or memory capacity of the mobile phone.
Mobile phones already do this to an extent, especially in their support for lots of different types of communication. Modern mobile phones can send email (we call this POP and SMTP support), they can access the Internet (with what is called a network stack) and they can save information to little memory cards. Mobile phones don't do all of these things at once. In fact, to preserve memory, processing power and battery life, mobile phones usually do one thing at a time. Therefore mobile phones already have a lot of services that can be called when they are needed.
We are going to extend that concept to office productivity applications.
A productivity application is actually a lot of different services that used by the person trying to be productive. Some of these functions are critical, but most of them are what might be termed optional. You don't need these services to be productive, but you might want to be able to call them. For example, you don't need a spell checker to type a letter, but you might want to use one after you have drafted the letter. The spell checker is a service, and we don't need to load it into memory until you specifically say “check my spelling now.”
If you reconceptualise an application as different services you can quickly create a map of how resource usage can be minimalised. Certain services such as drawing text (text rendering), understanding user input (keyboard driver) and outputting images to the screen (display driver) must be loaded at all times, but others services for saving documents, sending emails or checking grammar can load dynamically according to task requirements. An example of how this works is below:
Word Processor/Email client
|
Text and HTML render engine
Dictionary service (inactive)
Saving/sending service (inactive)
|
Java Virtual Machine
|
Mobile OS
Mobile SMTP/Network stack (inactive)
This looks awfully complex, but it's not really.
At the top of the pile there is a 'Word Processor/Email client,' which is a hypothetical application front-end. That's what the user of the mobile phone sees. It looks like a word processor that can also send emails. Below that there is a 'Text and HTML render engine,' which draws the text on the screen. Beside this there are other things like a 'Dictionary service' for spell checking and a 'Saving/sending service' that can help the end user save or email a document. These all run on a 'Java Virtual Machine,' which is an engine to run applications. This is already on most mobile phones, and it can be understood as a really powerful way to run programs on any phone or computer. At the bottom there is the 'Mobile OS,' (Operating System) which is the heart of the phone. It controls the basic functions of the phone, and stops and starts things like the Java Virtual Machine. The 'Mobile OS' works with the 'Mobile SMTP/Network stack' to allow communication on the Internet or through telephone calls.
Let's reverse direction, and go through that again.
At the very bottom of the example there is a preexisting Mobile OS running a simple Java Virtual Machine (Java VM). The mobile has a SMTP/Network stack which is inactive, but can be called by the Mobile OS when required. This means that the network stack is consuming no resources when it's not needed.
The Java VM is running a lightweight Text and HTML render engine. This can render (show) text and standard compliant (X)HTML. Given current standards, perhaps 'UTF-8' (text standard) support and 'XHTML 1.0 transitional' (web language standard) support would make the most sense. Because resources are limited, even this render engine might benefit from being modular. This would mean loading support for common rendering tasks into memory by default, but leaving out special sub-services that support unusual XHTML tags or the like. The render engine could accomplish this by only loading all rendering sections when it comes across an unknown XHTML tag.
Beside the Text and HTML rendering engine there are inactive services. These could include a dictionary service and a lightweight service for saving or sending the completed text and HTML files. These services would be wholly inactive until called, and when called might assume temporary control of the environment (pausing the user front end) to accomplish their task without memory or processor overload. This would have the advantage of minimising memory usage with the disadvantage of only allowing one task to be accomplished at a time.
The dictionary service is a fairly straightforward concept. A dictionary file would exist on the mobile phone, and so would a service to take the user input (what is written on the screen) and compare it to the dictionary file. The saving/sending service is more abstract. This would be a service designed to save the user input from the screen (the Random Access Memory; RAM) to the main memory (like a MMC card), or to take the user input from the screen and send it as an email through the SMTP/Network stack.
The top of the modular application framework is the application front-end. This would be a simple window with basic menu items (used to call the other modular services), and a canvas for user input. In most cases input would be textual (word processing, email, spreadsheet, database), but there is room for graphical input as well. It all depends on what services are running or can be called by the application front-end.
The application front-end would actually be pretty light, as all application 'actions' would actually be separate modules loaded dynamically as needed. The text and HTML render engine and any (option) graphic rendering engines would also exist below the front-end, providing essential services to all aspects of the user interface without requiring a large overhead.
By having a well designed modular framework such as this it should be possible to give the appearance of a complete network aware office suite using the limited resources available in a mobile phone. Best of all, because almost all services would be shared easily and openly, application development time would be dramatically reduced. Once primary services like the text and HTML render engine existed, creating a new application would largely consist of making a front-end and linking it to the services underneath. Adding a new service (like video decoding or a random number generator) would provide new functionality for all front-ends with a minor update.
It's all about cooperation, and sharing. The mobile office would actually not be an application or an application suite running on a telephone. It would be loads of little services calling each other when needed, and disappearing into the background when not required. At least in theory this could allow for quite complex ICT tasks to be accomplished with a very modest computational device.
All we need to build are mobile phones with two ports, some simple cables, and some smart software services. We are talking about a complete networked productivity solution. It's not a solution for the developed world, but in Africa, South Asia and Latin America it could make a massive difference. New phones for the rich, recycled phones for the poor. The devices would spread along existing channels, and supplement existing technology without requiring massive investment, training or logistics. Existing networks would carry the signals. Existing knowledge would empower the users.
$100 laptops are a great idea for the future, but people have mobile phones and TVs now. With a little effort we could really make that count for something, and take another step towards closing the Digital Divide.
This article is licensed under a Creative Commons Attribution 2.5 License (http://creativecommons.org/licenses/by/2.5/)
