-
Notifications
You must be signed in to change notification settings - Fork 15
Watch Specifications
The Proto Watch is designed to be a simple low cost device.
- Audio: Speaker, no mic
- Camera: None
- Input: 5 mechanical buttons
- Screen: 240-by-240-pixel resolution. 1.54” (diagonal) colour TFT display
- Capacity: 256MB Enough for a large amount of text, no video or images (beyond UI elements i.e. no photo, video or music library)
- GPS: Yes
- Expansion: None
- Networking: GPRS or less*
- Battery and Power: Built in rechargeable battery
- With regards to networking the actual speed depends on your target audience i.e. do some research but will be capped at GPRS speeds. Basically make Ajax network requests for JSON data
This functionality is built in, whist it can be customised it does not need to be built!
The watch is a low power device which should be able to run for several days without charging, the teams don’t have to worry about this.
The watch is capable of playing high fidelity audio using the AudioHub. Sound is not difficult to implement from a development perspective.
The watch does not have a camera or microphone, it cannot make video calls or take photos.
This is where a lot of the complexity can come in. As a standard, I have been happy to have the watch connect to the internet and fetch from API’s as needed. The amount you should allow is very dependant on how well the team is progressing and if they are taking on too much. For the purpose of implementation, it has proven easy to just mock everything. A simple function call that returns hardcoded data is fine for demo day and keeps the project on track without getting caught up in the details. When designing the product, teams can get carried away once they have access so feel free to reign it in, citing the mobile data usage.
It is assumed that the watch can share and receive information from other watches or a central server which the team have control over. Given the limited time in the course building developing server side software or actual integration across apps is strongly discouraged. There are some simple work arounds (remember they’re only building a prototype and only have about 24-48 hours during the course.
You can simulate data coming from another system or watch using the notification form in the demo app, or by loading JSON files into the StorageHub when the app starts. You can simulate sending information to another device by triggering notifications from the watch.
- If the watch can display data in a notification it can send it to another server or watch
- If the watch can read data from a JSON file it can access data from another system
- If a watch can write data to the StorageHub it can save information (StorageHub is not actually persistent)
- Getting a school time table
- Create a JSON file containing the time table information
- Notifying emergency services
- Display a notification with your GPS coordinates and the message you want to send to the emergency services
- Saving results from a quiz
- Display quiz results in a notification triggered by the watch (not the notification form)
- Alternatively: Write the data to StorageHub, and ignore the fact that the data is not saved
Some teams have successfully integrated with FireBase, Google Maps and other systems whilst some teams have struggled for the entire course to get the same thing working. Ultimately it depends on what the system is, how experienced the trainers are with the watch framework and how experienced the student developers are so you need to judge for yourself.
As Google Maps is technically possible and it’s just a big time sink you can just use a screen shot for demo purposes. Having students mess around with the API for actual solution can be frustrating for everyone. But remember for students to learn we need to find the right balance between faking everything and writing everything by hand.
See also Notifications and Storage
Commonly comes into play with a lot of teams. There have been no problems using HTML5 Geolocation or just hard coding some coordinates for demo purposes.
The watch can receive notifications. It is generally assumed that there is a central server the watches can communicate with and the teams have some control over e.g. a server in a school containing information about upcoming classes or test results. There is no need to build any server side functionality, it can be simulated using the notifications form in the demo app. Attempting to implement server side functionality is a rabbit hole you want to stay out of.
StorageHub is a key value store and could be hacked to store files easily enough. If people are unsure about how to implement it, you can limit it to just JSON data.
The StorageHub is a good way to fake data coming from a server without having to create APIs or integrate with other third party services.
It is pretty simple to find a solution to play video on the watch, however this can complicate the actual product design. If the team’s idea would benefit greatly from it, you could. I would however try to keep more of a basic usage of images / gifs.
The watch only has 5 physical buttons. Whilst you could put HTML input elements on a page these will not work well with the buttons. The general approach to capturing user input is to use the menupage and allow users to select items from a list.
See also Configuring watches
Common issue is students getting caught up on data input. If the data is unique to the user e.g. name
Example
- Students name, age, school timetable
- Assume the watch has been preconfigured or “flashed” by the school as part of a trial launch so no actual configuration options need to be build
- Preload data from a JSON file when the app starts
See also User input
The notification system can be used to send and receive messages but remember the limited options for user input. A simple solution is to have the watch pre-loaded with some common messages e.g. “Meet me at $gpsCoordinates” or “Are you attending $event”, “Yes”, “No” etc.
See also Notifications, Configuring watches