This is the continuation of part 2 blog post at: https://landing.athabascau.ca/pg/blog/read/72951/week-6-social-mobile-application-part-2-of-3

In answering some of the questions for week 6, I am listing the questions and answers below:

1.    What is the social forms the application is supporting?

a.    The Social Map Builder application takes the form of many-to-many community based group. Each registered member takes the role of both the producer and consumer of map data that are relevant to them. Collectively building map data that are maintained and consumed by members of the service – similar to what wikipedia and openstreetmap does.

2.    The affordances and constraints of the technologies you intend to use.

a.    I have detailed the system requirement in part 1 of this post.

3.    The effects of the users on your application and vice versa - what kinds of behaviours will it enhance, magnify, enable, what will it discourage or prevent?

a.    Since the social forms of the Social Map Builder application is similar to the form that wikipedia and openstreetmap takes. I would expect the similar effects in this community map building service. I would expect the application/service is going to be highly influenced by the network effect (http://en.wikipedia.org/wiki/Network_effect), making the underlying data more valuable as more and more user creates and consumes the content. As well, the majority of the users are going to be content consumer rather than producer, following the 90-9-1 rule (http://en.wikipedia.org/wiki/1%25_rule_%28Internet_culture%29) of the internet culture.

4.    Will you reuse and mashup existing systems or try to create one that stands alone? Why?

a.    I would chose to mashup existing systems simply of the low upfront cost to start up the service. In part 1 of my post I detailed that the application would use OSM/Bing for map data as well as weathernetwork for weather info.

5.    What kinds of privacy/security issues will you run into and how will you deal with that?

a.    As far as privacy concerns, there are individually identifiable information that are required when registered as the service member which would be kept private by default including name. For security, data will be properly encrypted in database as well as allowing the end user to select the visibility setting of each profile field. The only information that is shared publicly by default will be non-individually identifiable information such as route info.

6.    What kinds of cultural issues might affect this?

a.    The default language for this application/service will be english to begin with as this would capture a large percentage of internet users. Localization will be done and different language will be supported as the service grows.

7.    What kinds of technical issues would this cause?

a.    Certainly one of the main issues for realtime communication to server is the availability of the wireless network. Cellular towers are sparse in rural area causing “blind spots” for the mobile device, in which case, download/upload will be unavailable.

8.    Could it be made into something profitable? How?

a.    I believe so. Advertising is one avenue to bring in revenue to the business running the service. Targeted advertising can be done through the location awareness attribute of the device. For instance, display ads and suggestions of potential point of interest around the current location such as restaurants, bars, gas stations, etc.

9.    What are the technical limitations - does it need a particular kind of device, or infrastructure, or hardware, or software or site?

a.    In part 1 of this blog post I detailed the system requirement of the service. As long as the device is reasonably portable and supports the functions expected, it can be a tablet, smartphone, a lightweight laptop, etc. Also, since the service requires weather info so the dependent site must be available. The same apply to OSM server as data will be shared to OSM server.

10. How would it be constructed? I don't expect a great deal of detailed technical information about the design but there should be sufficient information about the architecture in broad terms to explain what it would need to operate and roughly how it might work.

a.    This is covered in blog post part 1.

11. Would there be a cold-start problem and, if so, how might you cope with that?

a.    Yes, there will be cold-start problem as route information takes time to build up by volunteers. So the application/services might not seem as attractive at first due to the lack of shared content - route information. I would consider delaying the official launch of the application/service until a sufficient amount of content is build up by hired individuals.