Watch+Strap Web Prototype
Usage
Firstly, run
npm install
For production usage, please use
npm start
This will create a background process for running the server.
For debugging, there are two ways:
npm run-script debug-local
This starts the server locally; all communication happens via the local server.
npm run-script debug-remote
This starts the server as before, but redirects the clients to connect to a remote websocket server. The address is read from the DEBUG_REMOTE_ADDRESS property from the .env file (must be created manually).
Config
Right now, you can create a .env file for some a few simple configurations. Example:
PORT=31415
DEBUG_REMOTE_ADDRESS=127.0.0.1
Hints
- Currently, only the Chrome browser is supported
- to avoid accidential website zoom interaction on tablet prototype, start chrome with
chrome.exe --kiosk --disable-pinch --overscroll-history-navigation=0
Development / Structure
Server: The server component is a nodeJS file that runs the websocket server as well as serves the frontend. The server itself only forwards messages as well as supports some image data transformations for the eink displays.
Frontend: The application logic is placed in the frontend, mostly in the main.mjs file. The frontend must be opened on a computer in order to run the prototype!
The Main class receives the websocket messages from the watch as well as eink displays (forwarded by the server) and updates the application accordingly.
Apps: The prototype follows a lightweight app structure, which can be loaded via the drawer app.
These apps are implemented in ES module files (.mjs) and are children of the APP class (app.mjs).
The apps must be imported and added to the _availApps list in the constructor of the Main class (main.mjs).
When initialized, apps expect three Surfaces; within these surfaces SVG / D3.js can be used to implement the interface.
Surfaces: During run time, there are three surfaces, one for each display (watch, lower strap, upper strap).
Technically, each surface is a special object (see surfaces.mjs) and holds references to the respective iframe and its properties (e.g., document object, D3 instance, SVG element) as well as further properties describing the corresponding display (e.g., size, color mode, dpi).
SSVG: The SVG element of each surface is not drawn but mapped to a canvas object during runtime; this is done using the SSVG library. While this happens almost transparently, SSVG does not support all D3/SVG features yet. For more details, see https://github.com/michaschwab/ssvg.