I think that it's good to throw something out here to get started from the IT side of the house, so here are five requirement that I think go along with this platform.
From a user point of view, it's not clear exactly what class of users you're talking about. I don't think you're trying to support the affected population, although the paragraph about mobile phone subscribers and Internet penetration suggests you are. In any case, I think we can come up with some guidelines that might apply no matter who the end-user is.
First, there is a clear direction for web-based applications to be the base for everything nowadays. In the case of the directions in the earlier consultations, there is nothing here which would require a heavy-weight client or massive amounts of client programming. So from a technology point of view, you'd have these basic design requirements:
1- built to run in browsers, without unnecessary plugins (ActiveX, Flash, Java, Silverlight)
2- responsive interface (Responsive is a term of art for web designers that indicates a web site that "knows" it is being looked at on a small screen such as a tablet or phone and behaves differently; everyone reading this should have encountered this phenomenon already as they switch between well-known sites on laptop, tablet and phone)
Within the platform, it seems like you will want to have multiple sub-applications. These, I think it is obvious, should be able to be plugged (and possibly unplugged) easily without re-engineering the system. For example, one 'sub-application' might be a discussion forum where people can pose questions and get help from the community to answer them. Another might be a calendar sub-application where participants can share information about events, conferences, webinars, etc. Over time, it might be discovered that the calendar is not useful, and so it should be easy to unplug. And over time it might be discovered that there is a need for some sort of collaboration/training piece (as has already been mentioned), so this should be easy to plug in.
I think that the designers will find this simpler to deal with if the whole project is thought of as modular, rather than monolithic. In other words, let's not have an extended debate on exactly what modules have to be there on day 1, but come up with different options and use rapid prototyping to get things going, then add as the user community finds needs for additional modules. Think of this as an extended and permanent development project, rather than a one-time development process that ends and is static for all time.
Thus, requirement 3:
3- agile framework, easy to expand to add new internal applications
In general, we find that platforms like this are all competing for the attention of the end-user, and the sense of community will be hard to create. We absolutely cannot depend on people coming to this web site on a regular basis unless they are being 'pulled' to it by other forces. So a key part of the core will have to be creating an entitlement system and linking to some sort of authentication/user profile. (Entitlement is a term of art here which can also be used to indicate subscriptions, interest areas, privilege levels, etc. In this sense, entitlement is a generic term for all of these things.) Folks like Facebook and Google are happy to act as authentication service providers, and it's not unreasonable to use those open systems to both eliminate your need to handle authentication but also to make it easy for people to link up. (Some folks will insist on a separate identity, but this is likely to be a fringe corner case)
Once entitlement/authentication is handled, then the system can provide push content to the end users to pull them back to the platform when there are updates in areas they are interested in, when questions they have posed are being discussed, and periodically just to give updates on new content (i.e., monthly or weekly digests). This is really critical to building and sustaining a community; without it, the user population will inevitably devolve into a small set of non-representative people who spend all their time shouting at each other.
Thus, requirement 4:
4- assumption of a "push" model from web site to users, rather than expecting that users will be coming by to participate without prompting
One final requirement comes from the need to ensure that the system meets the needs of the users. In a system like this, there is always a combination of "evergreen" content (i.e., white papers, technical and non-technical resources, documents) and "collaborative" content (i.e., discussions, Q&A, open forums). Collaborative content tends to decay quickly over time, as the topics being discussed become old or the discussion itself is too long to be interesting to a consumer. Thus, any sort of collaboration has to be combined with moderation and, more importantly, curation. There must be participants in the system who have some incentive to overcome the entropic decay and work to winnow content, create summaries, and so on.
The key here is "incentive," as without it, this will inevitably fail. Now, this is definitely not a technical requirement, but technology can help with this. For example, most readers will have noticed "badges" that are constantly being given out by web sites (everyone from Amazon on down) to their high-volume contributors. Some of this will need to be dealt with out-of-band (i.e., someone will be paid to be a "gold contributor"), but the technology has to support this by providing tracking to recognize valued contributors.
5 - internal measurement system to provide feedback to users who are valued contributors about their status (and to report this externally as needed)
Some thoughts on a platform…
I think that it's good to throw something out here to get started from the IT side of the house, so here are five requirement that I think go along with this platform.
From a user point of view, it's not clear exactly what class of users you're talking about. I don't think you're trying to support the affected population, although the paragraph about mobile phone subscribers and Internet penetration suggests you are. In any case, I think we can come up with some guidelines that might apply no matter who the end-user is.
First, there is a clear direction for web-based applications to be the base for everything nowadays. In the case of the directions in the earlier consultations, there is nothing here which would require a heavy-weight client or massive amounts of client programming. So from a technology point of view, you'd have these basic design requirements:
1- built to run in browsers, without unnecessary plugins (ActiveX, Flash, Java, Silverlight)
2- responsive interface (Responsive is a term of art for web designers that indicates a web site that "knows" it is being looked at on a small screen such as a tablet or phone and behaves differently; everyone reading this should have encountered this phenomenon already as they switch between well-known sites on laptop, tablet and phone)
Within the platform, it seems like you will want to have multiple sub-applications. These, I think it is obvious, should be able to be plugged (and possibly unplugged) easily without re-engineering the system. For example, one 'sub-application' might be a discussion forum where people can pose questions and get help from the community to answer them. Another might be a calendar sub-application where participants can share information about events, conferences, webinars, etc. Over time, it might be discovered that the calendar is not useful, and so it should be easy to unplug. And over time it might be discovered that there is a need for some sort of collaboration/training piece (as has already been mentioned), so this should be easy to plug in.
I think that the designers will find this simpler to deal with if the whole project is thought of as modular, rather than monolithic. In other words, let's not have an extended debate on exactly what modules have to be there on day 1, but come up with different options and use rapid prototyping to get things going, then add as the user community finds needs for additional modules. Think of this as an extended and permanent development project, rather than a one-time development process that ends and is static for all time.
Thus, requirement 3:
3- agile framework, easy to expand to add new internal applications
In general, we find that platforms like this are all competing for the attention of the end-user, and the sense of community will be hard to create. We absolutely cannot depend on people coming to this web site on a regular basis unless they are being 'pulled' to it by other forces. So a key part of the core will have to be creating an entitlement system and linking to some sort of authentication/user profile. (Entitlement is a term of art here which can also be used to indicate subscriptions, interest areas, privilege levels, etc. In this sense, entitlement is a generic term for all of these things.) Folks like Facebook and Google are happy to act as authentication service providers, and it's not unreasonable to use those open systems to both eliminate your need to handle authentication but also to make it easy for people to link up. (Some folks will insist on a separate identity, but this is likely to be a fringe corner case)
Once entitlement/authentication is handled, then the system can provide push content to the end users to pull them back to the platform when there are updates in areas they are interested in, when questions they have posed are being discussed, and periodically just to give updates on new content (i.e., monthly or weekly digests). This is really critical to building and sustaining a community; without it, the user population will inevitably devolve into a small set of non-representative people who spend all their time shouting at each other.
Thus, requirement 4:
4- assumption of a "push" model from web site to users, rather than expecting that users will be coming by to participate without prompting
One final requirement comes from the need to ensure that the system meets the needs of the users. In a system like this, there is always a combination of "evergreen" content (i.e., white papers, technical and non-technical resources, documents) and "collaborative" content (i.e., discussions, Q&A, open forums). Collaborative content tends to decay quickly over time, as the topics being discussed become old or the discussion itself is too long to be interesting to a consumer. Thus, any sort of collaboration has to be combined with moderation and, more importantly, curation. There must be participants in the system who have some incentive to overcome the entropic decay and work to winnow content, create summaries, and so on.
The key here is "incentive," as without it, this will inevitably fail. Now, this is definitely not a technical requirement, but technology can help with this. For example, most readers will have noticed "badges" that are constantly being given out by web sites (everyone from Amazon on down) to their high-volume contributors. Some of this will need to be dealt with out-of-band (i.e., someone will be paid to be a "gold contributor"), but the technology has to support this by providing tracking to recognize valued contributors.
5 - internal measurement system to provide feedback to users who are valued contributors about their status (and to report this externally as needed)