Difference between revisions of "Inclusive Models"

From wiki.gpii
Jump to: navigation, search
(Misconceptions Table)
(Misconceptions Table)
Line 10: Line 10:
 
</gallery>
 
</gallery>
  
{| class="wikitable" style="text-align: right;"
+
{| class="wikitable" style="text-align: left;"
 
|'''Domain'''
 
|'''Domain'''
 
|'''Old Way of Thinking/Doing : Misconceptions & Ruts'''
 
|'''Old Way of Thinking/Doing : Misconceptions & Ruts'''

Revision as of 19:37, 11 February 2016

The infrastructure teams are asked to explore their practices and assumptions, note where they are falling into the ruts or misconceptions outlined in the misconceptions table below, and explore the design and economic models from SP1 to adapt their processes to achieve greater inclusion. A key part of the SP1 models is a loop of continuous feedback that leads to refinement of the models to ensure they better address the needs of the infrastructure teams while solving complex problems for unique users.

  • The Design kit including the Use Model, Design Specifications, and Inclusive Design Guides can be found here [1].
  • The economic and ecosystem model analysis can be found here [2].

Misconceptions Table

The ‘Misconceptions’ table contrasts the typical approaches (in various domains) that have failed with new ways of thinking and doing that are driving the paradigm shift needed for making the vision of P4A possible.

Domain Old Way of Thinking/Doing : Misconceptions & Ruts New way of Thinking/Doing : Paradigm Shift Tools and Methods
Development & Design
  • Isolated (stand alone functions) work packages that snap together when completed
  • Require responsive system in quickly changing context with undefined and expanding scope
  • Functions are entangled and interdependent
  • Need built-in ability to incorporate early trial, error and feedback by users and iteratively respond to this
  • Be flexible and porous
  • Create conditions for growth, new uses and connections
  • see D103.1 section 4.2.1 Global Design Specifications
Project Management
  • The roadmap can be predicted and controlled
  • We can know the problem and create a solution
  • Can be solved in a standard, linear manner
  • We can control this and predict requirements
  • There is an end point when the project is complete and we have succeeded
  • This is a complex project and so adopting a ‘complex project management’ approach is appropriate (inspired by system of systems )
  • require ongoing transparent communication
  • Emergent systems cannot be *known* and planned in the same way
  • “Success” continues to evolve and change
  • D404.1 for more information
Users
  • Working from deficit model of disabilities
  • We can create persona categories that represent most of the possible end users - they have static needs
  • The only end users are people with disabilities
  • The system is built from a perspective of inclusion and one-size-fits-one
  • This ecosystem is built to empower users and break down barriers to access -- regardless of user ability or disability
  • Personae are meant to help model the range of behaviours, not represent full demographics of complex and unique people
  • see Design Kit D103.1 section 1.4
Design
  • Inclusive design isn’t necessary or important -- it’s the touchy/feely stuff
  • Inclusive Design is design that is built upon common design practices with additional principles, practices, and tools used for the benefit of all end-users. It’s better design.
  • We are designing for diversity, inclusive design is needed to design for diversity not the mass
  • see Inclusive Design Guide D103.1 section 4.3
Economic
  • Accommodations represent all new costs, but not investments
  • Prosperity is monolithic
  • We need “full social costing” showing macro and long-term impact of investment
  • Prosperity is not just measured as “more money in my pocket”
  • Prosperity should happen (and be measured) at the “micro” and “macro” levels
  • Costing models need to incorporate collective costs taking into account sharing and collective production
  • see D102.2 and D404.2 deliverables
Timing
  • Emergence is a quick process - just a state change not an evolving one
  • Emergence will happen through use and feedback and adjustments
xx
Architectural
  • We can engineer a fix - technology can solve it all and we are smart people who know what is best
  • The engineers are not the only ones building this system -- it is designed to encourage feedback and adapt and grow based on end-user feedback and use
  • We are dependent on all users/stakeholders from the demand to supply side of the system for the solutions and guidance for iterative refinement
  • This needs to be self-healing, self-correcting, and self-refining
xx
Market
  • The sustainable business model is just “details” that someone else can work out
  • There can just be one business model that will work
  • Business model is more than just payment systems
  • Solutions need to adapt to users and user context and evolve over time
  • D102.2 deliverable

Feb 2016 Webinar

The main objective of the Feb 2016 webinar is to provide the infrastructure teams with a brief and clear description of the SP1 design and economic models and their applications. The following image lists the items that will be discussed during the webinar.