Difference between revisions of "Team MaybE"

From mn/ifi/inf5750
Jump to: navigation, search
 
(9 intermediate revisions by 2 users not shown)
Line 4: Line 4:
 
* Lars Kristian Roland Wærstad (lkwaerst@uio.no)
 
* Lars Kristian Roland Wærstad (lkwaerst@uio.no)
 
==Summary of requirements==
 
==Summary of requirements==
===Design options===
+
======Design options======
 
* When to load organisation units
 
* When to load organisation units
 
* How the website will look
 
* How the website will look
===Technologies used===
+
* How the user can interact with the map
 +
======Technologies used======
 
* React / Redux
 
* React / Redux
 
* JavascriptHtml / css with bootstrap
 
* JavascriptHtml / css with bootstrap
 
* Git
 
* Git
 
* DHIS2 API
 
* DHIS2 API
* Mapzen API
+
* Mapzen
* Google Maps API
 
 
* Google Translate API
 
* Google Translate API
 
* Wiki
 
* Wiki
====Features sorted by priority classes====
+
======Features sorted by priority classes======
 
* Map showing health facilities (1)
 
* Map showing health facilities (1)
 
* Filter functionality by a search bar (1)
 
* Filter functionality by a search bar (1)
Line 24: Line 24:
 
* List health facilities from any chosen countries (3)
 
* List health facilities from any chosen countries (3)
 
==Time schedule==
 
==Time schedule==
===Halfway point (14.november)===
+
======Halfway point (14.november)======
* All essential features should be functionalHow you are dividing tasks within the group
+
* All essential features should be functional
 +
 
 
==How you are dividing tasks within the group==
 
==How you are dividing tasks within the group==
 +
* Espen Volnes: List functionality and DHIS2 API handling
 +
* Matthias Wenger: Map functionality and Mapzen API
 +
* Lars Kristian Roland Wærstad: Filter functionality and user input
 
==Screenshots and screen flows==
 
==Screenshots and screen flows==
 +
[[File:Team maybeE flow.png]]
 
==Documented learning during project==
 
==Documented learning during project==
 
==Suggested improvements to APIs etc==
 
==Suggested improvements to APIs etc==
Line 33: Line 38:
 
https://github.uio.no/espenvol/INF5750
 
https://github.uio.no/espenvol/INF5750
 
==Download link to sample web app==
 
==Download link to sample web app==
 +
 +
==Summaries of papers==
 +
======Balancing platform control and external contribution in third‐party development======
 +
The paper introduces a new general model for understanding the design of boundary resources.
 +
The model provides a solid theoretical foundation to examine platform ecosystems where
 +
a platform owner develops boundary resources designed to be used by third party application developers.
 +
 +
The model describes the process of designing boundary resources as
 +
a balancing act between two conflicting forces. Resourcing and securing.
 +
Resourcing is the process of expanding the scope/diversity/access to the
 +
platform, this makes it possible for third-party developers to develop applications
 +
with new functionality. Securing is the process of controlling/limiting the use
 +
of the platform. This limits the possibilities of third-party developers, and
 +
is used by the platform owner to control third party developers with conflicting(to the platform owner) interests.
 +
 +
The case study of apple from the paper identifies 4 different manifestations of
 +
these two concepts.
 +
1 - Self-resourcing is when third party application developers
 +
take matters into their own hands. They circumvent the boundary resources created by
 +
the platform owner to gain direct access to the platform. This leads to third party developers
 +
creating their own frameworks and interfaces, and leaves the platform owner with no control of
 +
the access to their platform. Self-resourcing is an indicator of too much securing (too restrictive), and not enough
 +
resourcing in the design of the boundary resources.
 +
 +
2 - Diversity-resourcing is when the platform owner enhances the existing boundary resources.
 +
Either proactively to draw in more application developers, and allow for more diverse applications,
 +
or reactively in response to feedback from third party developers.
 +
 +
3 - regulated-securing is a form of securing that restricts the possibilities of third party developers
 +
by imposing regulations on the use of the boundary resources. The third party developers have to
 +
follow the regulations to gain access to the boundary resources of the platform.
 +
 +
4 - Sovereignty securing is a specific form of securing where the goal is to remove/keep away other parties (4th parties) from the platform ecosystem.
 +
An example of this would be a different platform making use of the boundary resources of the platform owner. This adds a layer between the
 +
original platform owner and their third-party developers, which makes the original platform owner dependent on a different platform (4th party) to some degree.

Latest revision as of 10:55, 11 November 2016

List of group members

  • Espen Volnes (espenvol@uio.no)
  • Matthias Wenger (matthiw@uio.no)
  • Lars Kristian Roland Wærstad (lkwaerst@uio.no)

Summary of requirements

Design options
  • When to load organisation units
  • How the website will look
  • How the user can interact with the map
Technologies used
  • React / Redux
  • JavascriptHtml / css with bootstrap
  • Git
  • DHIS2 API
  • Mapzen
  • Google Translate API
  • Wiki
Features sorted by priority classes
  • Map showing health facilities (1)
  • Filter functionality by a search bar (1)
  • List all plotted health facilities (1)
  • Select district on map to show health facilities from (2)
  • Choose language using google translate (3)
  • List health facilities from any chosen countries (3)

Time schedule

Halfway point (14.november)
  • All essential features should be functional

How you are dividing tasks within the group

  • Espen Volnes: List functionality and DHIS2 API handling
  • Matthias Wenger: Map functionality and Mapzen API
  • Lars Kristian Roland Wærstad: Filter functionality and user input

Screenshots and screen flows

Team maybeE flow.png

Documented learning during project

Suggested improvements to APIs etc

Link to repository

https://github.uio.no/espenvol/INF5750

Download link to sample web app

Summaries of papers

Balancing platform control and external contribution in third‐party development

The paper introduces a new general model for understanding the design of boundary resources. The model provides a solid theoretical foundation to examine platform ecosystems where a platform owner develops boundary resources designed to be used by third party application developers.

The model describes the process of designing boundary resources as a balancing act between two conflicting forces. Resourcing and securing. Resourcing is the process of expanding the scope/diversity/access to the platform, this makes it possible for third-party developers to develop applications with new functionality. Securing is the process of controlling/limiting the use of the platform. This limits the possibilities of third-party developers, and is used by the platform owner to control third party developers with conflicting(to the platform owner) interests.

The case study of apple from the paper identifies 4 different manifestations of these two concepts. 1 - Self-resourcing is when third party application developers take matters into their own hands. They circumvent the boundary resources created by the platform owner to gain direct access to the platform. This leads to third party developers creating their own frameworks and interfaces, and leaves the platform owner with no control of the access to their platform. Self-resourcing is an indicator of too much securing (too restrictive), and not enough resourcing in the design of the boundary resources.

2 - Diversity-resourcing is when the platform owner enhances the existing boundary resources. Either proactively to draw in more application developers, and allow for more diverse applications, or reactively in response to feedback from third party developers.

3 - regulated-securing is a form of securing that restricts the possibilities of third party developers by imposing regulations on the use of the boundary resources. The third party developers have to follow the regulations to gain access to the boundary resources of the platform.

4 - Sovereignty securing is a specific form of securing where the goal is to remove/keep away other parties (4th parties) from the platform ecosystem. An example of this would be a different platform making use of the boundary resources of the platform owner. This adds a layer between the original platform owner and their third-party developers, which makes the original platform owner dependent on a different platform (4th party) to some degree.