We The Curious Developers

We The Curious Developers

  • Guidelines
  • CuriOs SDK
  • Software
  • Films
  • Art
  • Audio
  • Photography

›Getting Started

Getting Started

  • Getting Started Overview
  • ClI
  • Working With Us

Technical

  • Hardware

Frames

  • Frames Overview
  • Info Panel
  • Media Browser
  • Touch to Start

Components

  • Components Overview
  • Box
  • Button
  • Card
  • Checkbox
  • Header
  • Heading
  • Hero
  • Icon
  • Text Input
  • Markdown Viewer
  • Modal
  • WTCProvider
  • Table
  • Text
  • Video Player
  • Calendar
  • Dropdown
  • InputAutoComplete
  • Radio
  • Sidebar
  • Slider
  • Notification
  • IconNavButton
  • IconSideBar
  • List
  • Tab
  • Title
  • Toggle
  • Value

Getting Started

This section is an overview of how we approach working together It is not a legal agreement to be used as a reference in lieu of a contract.

General Approach

Terminology

When developing for We The Curious there are many considerations, particularly for complex builds and so terminology can become ambiguous. This is for clarification. We try to use these terms consistently, but sometimes we don't

Exhibition Space

The entire publicly accessible interior of We The Curious

Exhibition

A Exhibition is an area containing one or more exhibits

Constellation

A sub grouping of exhibits within an exhibition space (Currently specific to project what if)

Exhibit

A single experience 'package' including the hardware, housing, setwork and software

Experience

An exhibit with additional considerations of how it appears in the space and how a user approaches the exhibit before interaction.

App

The application running the exhibit. An app will generally belong to one exhibit, but may belong to multiple.

Service

A service is a single piece of software. Generally an App will have one service but it is possible for an App to have multiple services for example when there are two different interfaces controlling different parts of the exhibit.

Instance

Exact copies of an exhibit, app or service running to provide an identical experience at multiple points

Version Control

Development must be version controlled in git. We will provide a link to a remote repository which should be used for all push commands

We use git flow pattern for branch naming in git. We prefer that you use this pattern but it is not a requirement, except for master and develop branches as these are used for our CI process.

Continuous Integration

To provide continuous feedback to the content team at We the Curious. We are setting up a CI process for delivering apps to exhibits in prototyping or on the floor.

Our default deployment target for interfaces is web apps running on brightsign players. If you are using this for your development we have a preset CI process using the bitbucket deployments feature. When you push to master or develop bitbucket does some setup and then copies the build to S3. The brightsign players periodically check the S3 buckets for updated objects and download them for use. Code pushed to the master branch will be pushed directly to the exhibition floor while code pushed to develop will go to the prototype rooms.

If you are not using our default deployment target then how we manage and review updates will need to be negotiated on a per project basis

Licensing

This section is an overview of how we approach licensing. It is not a legal agreement to be as as reference in lieu of a contract.

Code that is developed by you for us to our spec is owned by us unless there has been a contract stating otherwise. We like to work with an assumption that the code is to be released open source. We generally will decide to release open source unless there a reason not to - usually security or third party licensing.

We are currently looking for the default license we wish to use for open source.

The license you agree with us only covers the code you have developed for us under the contract. It does not extend to packages developed by you or third parties.If you intend to use packages that are proprietary you must provide documentation of what those packages are, what their function is in you software.

'Code you have developed for us' generally will be defined as code committed to the repo. If you have code that you don't want to be caught by the license please require it as a dependency.

Documentation

We do expect documentation to be provided as part of the development process. The should be supplied as a readme.md in the git repo. You must detail. The documentation should be written in such a way to be understood by a competent developer who has no previous experience of the language or environment used.

  • Authors of the software

  • The intent of the software

  • A step by step install process, including environment set up

  • License used for the software in the repo

  • Details of packages used and license information

  • Screen shots of the main screens

Examples

Our current ticketing site is the first application to be built with the SDK. You can use it here

Last updated on 5/8/2019
← ClIHardware →
  • General Approach
  • Terminology
    • Exhibition Space
    • Exhibition
    • Constellation
    • Exhibit
    • Experience
    • App
    • Service
    • Instance
  • Version Control
  • Continuous Integration
  • Licensing
  • Documentation
  • Examples
Docs
Getting Started (or other categories)Guides (or other categories)API Reference (or other categories)
Community
User ShowcaseStack OverflowProject ChatTwitter
More
BlogGitHubStar
Copyright © 2020 We The Curious