Talks by Doug Reeder

WebXR for Web Developers

2024-08-07T00:00:00Z

Delivered to VRColumbus in May 2024 and ColumbusJS in August 2024

Slides #

vs. native #

Native apps can fully utilize hardware, but are siloed in development and distributed by gatekeepers
Web apps can reach anyone, but you must allow for differing capabilities and can't achieve the performance of native
- may also run on personal computers or mobile (depending on interactions), for those without a headset
- could have presenter(s) in headset and audience mostly on personal computers or mobile

Browser Graphics #

everything displayed in a window is in Document Object Model (DOM)
conventional web programming comes down to manipulating the DOM, using a weakly-typed language w/ automatic memory management
almost the polar opposite of environment for high-performance graphics

APIs for WebXR #

Full-screen mode eliminates windowing & browser chrome, for immersion
Canvas is HTML Element (in the DOM) you can draw into
- covers rectangular part or all of window
- bitmapped
- doesn't contain DOM, nor retain your draw calls
current: WebGL 2: context of HTML Canvas
- based closely on OpenGL ES 3.0,
- you will program to a utility library (or else wind up writing your own)
- focus is on the shader program
  - libraries have all standard shaders
  - custom shaders for unusual cases
  - example: aframe-shader-buildings
    - each building is just an ell-shaped box made from 12 triangles; all buildings of a style are one object
    - switches from texture for walls to cubemap for windows
- Shaders written in GLSL a C-like language (you serve GLSL files just like HTML, CSS & JavaScript)
future: WebGPU in progress
- new kind of Context for HTML Canvas element
- no baggage from 1990s
- supports modern GPU architectures
- abstraction on top of Vulkan, Metal & DirectX 12
- focuses on resource re-use via "pipelines" & "RenderBundles"
WebXR: A web standard for working with VR & AR
- complements WebGL/WebGPU
- VR/AR life-cycle
  - start & stop immersive & AR modes
  - frame timing (may be different than main display)
- provides new inputs
  - head pose for camera
  - Controller position and buttons
  - Hand tracking
  - transient inputs (like laser pointer): mobile tap or Vision OS click
- exposes platform features like AR plane detection
WebAssembly (WASM)
- near native speed
- just computation, no DOM access nor I/O
- support for strongly typed languages; around 40 programming languages reportedly compile to WASM
- physics engines, SLAM engines
- 2.0 in draft
- developer survey: need for improvement in four areas: WASI, debugging support, integration with JavaScript and browser APIs, and build tooling

Performance #

Decide your target device class: mobile (billions), standalone headsets (10s of millions), or personal computers (millions)
To keep frames/sec up, watch these metrics
- number of triangles per frame:
  - mobile: < 100,000–200,000
  - standalone headsets: < 750,000–1,000,000
- draw calls per frame:
  - mobile: < 100–150
  - standalone headsets: < 100–175
metrics
- draw calls: not much more than 100 draw calls (object & material) on mobile, including standalone headsets
- number of triangles

Google <model-viewer> #

only displays 3-D models
web component (element in DOM tree)

Frameworks #

Three.js
- imperative programming
- low-level; more code needs to be written than other frameworks
- minimal dev tools
- no built-in physics engine, but almost every physics engine documents how to use with Three.js
- extensions tend to be low-level
  - example: subdivision vs. glow (halo)
- experimental support for WebGPU
Babylon.js
- One True Way to do things; reputation of steeper knowledge curve
- built-in support for almost anything you need (but if it doesn't work the way you need, you may be out of luck)
- physics engine: Cannon.js or Oimo
- community contributions
- tools like Playground
- most features support using WebGPU
A-Frame
- Easy to get started; simplest scenes just require HTML
- Programming guidelines, but you can do what you like
  - also, open-source chaos
  - impedance change when you get down to Three.js level
- A-Frame Inspector, like browser tools
- no built-in physics engine
- a component for anything you want to do (for example, Gaussian Splatting), but it may not be maintained or work with latest. In particular, many components were written for earlier versions of Three.js that use WebGL 1
- many components are just wrappers for Three.js functionality
- Lower layers use Three.js; awkward to use Three.js plugins
- A-Frame component built on Three.JS extension

Engines #

Unity (exporter plugin)
- not web-friendly,
  - long load times
  - minimal access to web APIs
  - can't get help via posting a simple example online
- not all Unity capabilities
- experimental support for WebGPU
- good for showing off a single level of a native game
PlayCanvas
- integrates with ammo.js physics engine
- visual editor
- rendering optimized for mobile
- built-in code, editor, less friendly to using your own IDE
- WebGPU support in development
8th wall
- SLAM engine doesn't depend on WebXR API (so runs on iPhones)
- focussed on AR advertising campaigns
- expensive
- must build on top of a framework such as A-Frame
Wonderland
- several excellent example games
- free up to $120k/yr
others with less mind-share
- Godot
  - 2-D & 3-D game engine for native
  - impedance mismatch with WebXR
- Elixir
  - Rapier physics engine
  - compatibility w/ Three.js plugins
- Cocos Creator
  - 2-D & 3-D game engine for native
  - supports WebGPU
- Etherial

Tools for non-programmers #

LearnBright
- "learning modules" only
MetaVRse Engine

Development (generally) #

3D file formats: GLTF/GLB with many frameworks offering support for older standards like OBJ, STL and proprietary standards like FBX, USD.
Can use multiple threads via Workers & WebAssembly (but it's awkward and less efficient than native)
Weakly typed languages can be transpiled to JavaScript
Strongly typed languages can be compiled to WebAssembly
Pick a framework or engine — begin with the end in mind
- game vs. experience vs. presentation
  - physics engine required?
- try framework examples, on your target platforms, to see what apps are focussed on
- licensing / who's backing it? / how long will your project be maintained?
  - Amazon abandoned Sumerian in 2022
- What you're familiar with
In any framework, you may need to write/re-write a component to do what you need
Browser extension: WebXR API Emulator
Standalone headsets: chrome://inspect/#devices
3D file formats: GLTF/GLB with many frameworks offering support for older standards like OBJ, STL and proprietary standards like FBX, USD.
Can use multiple threads via Workers & WebAssembly (but it's awkward and less efficient than native)
Weakly typed languages can be transpiled to JavaScript; strongly typed languages can be compiled to WebAssembly

Development Support #

WebXR discord
Framework forums / communities
Voices of VR podcast has done many episodes on WebXR and the broader Immersive Web community.

Browser & OS Support #

Quest 2/3/Pro #

Oculus Browser: full support
Wolvic (based on Firefox): supports basic features

Pico headsets #

Firefox may or may not still work
Wolvic (based on Firefox): supports basic features

Vision OS #

Safari: enabled by default in VisonOS 2

Personal Computers #

Chromium browsers: most features
Safari: behind flag
Firefox behind flag, no longer maintained
Opera: many features

Android #

Chromium browsers: most features including AR

iOS #

Safari: not implemented
other browsers (only in Europe for now) ?

Linux #

Chromium browsers: experimental support

Outstanding WebXR sites #

Wol: Mixed-reality, voice interaction
VRPlanets: learn orbital mechanics
3DStreet: urban planning
Moonrider: Beat Saber clone
Project Flowerbed: interactions

Live-coding #

code repo
A-Frame environment components
A-Frame components
multi-user world — if you don't have a friend handy, open two windows

Join the Cool Kids — If You're Allowed! — The Web Share APIs

2024-03-06T00:00:00Z

Delivered to ColumbusJS in March 2024

Bio #

Doug Reeder has been programming professionally for a quarter century on a wide range of technologies, at organizations large and small. Today he does full-stack web development, consults on WebXR, and pushes back on gatekeepers.

Outline #

1974: GUI Copy & Paste #

Larry Tesler & Tim Mott @ Xerox PARC
App to App within device, only
Text, later other data types
later: Drag & Drop

Few people had direct Internet access; PDAs didn't have IP networking
Exchange Manager; originated Gavin Peacock
- IR beaming range 3 feet (OBEX IrDA; Pocket PC 2002 and later)
- Bluetooth in Palm OS 4
IR beaming is fast enough for business cards, calendar events, memos (text only). If you're patient, you can share apps or the smaller pictures used back then
Available, but underutilized, within device:
- Resco Explorer lets you receive zip archives
- SiEd lets you receive and edit .c, .html, and .php files
- VFSExchange (2006) — used mostly for ringtones & Java Midlets

Non-enthusiasts didn't use Beaming — unclear why.

Video of IR beaming [if time]

devices exchange URLs
paradigm is "share what's on the screen"
video of Zap Photoshare: https://www.youtube.com/watch?v=2oLfKqpUJT4

Big demand to share URLs from and to Social Media
Selecting content on handhelds is tricky, so copy-and-paste is high-friction. ⇒ demand for sharing within device
Native share targets:
- social media
- email
- messaging
- file storage
- file transfer
- print service
- content transformers (e.g. text-to-speech, Google Lens)
Browsers already have menu command to share URL of whole page
Android offers to Share anything copied to the clipboard
A number of browsers accept shared text, and do a web search with it

original: asynchronous navigator.share()
- can send part of page, or even content that isn't in page at all
- requires transient activation (typically a user click)
- title, text & url fields
  - can't send multiple URLs nor texts
- sender dumps it over the wall, receiver free to ignore fields it doesn't want to deal with
- typically use text or url, not both. Can't be sure what receiver will actually use
- widely supported (Firefox on Android won't send text)
later: synchronous navigator.canShare()
- if data in one form is disallowed, you can send in another format
- almost only use is whether the browser allows new files field at all
  - won't tell you if file type is disallowed :-(

Small signature, complicated use #

url > text, file > text; safest to not send url & files; may need to offer more than one Share option
URLs: can send if API supported at all
- sending multiple URLs requires multiple user clicks
- only http: and https: schemes
- aside: theoretical possibilities that probably won't materialize: tel: mailto: sms: mms: irc: sip: xmpp:
text: call canShare(), fall back to simulating click on mailto: anchor
files: multiple ways to fail
- no API
- canShare()
- file type rejected by share()
- If your use case allows, can fall back to different type (plain text or PDF), text field, thence to mailto: anchor
- Notes Together will try up to four different ways to send a note

text/plain
text/html
text/csv
text/css — why?

text/tab-separated-values
text/calendar
text/vcard (iOS Contacts share target)
text/markdown
text/rtf
text/javascript
text/p .p
text/awk .awk
text/uri .uri
text/gltf

Title, text, url, files: https://w3c.github.io/web-share/demos/share-files.html
Files: https://scrapbook-pwa.web.app/

installed PWA (requires Web App Manifest & Service Worker)
browser & OS that supports
add to Web App Manifest:

"share_target": {
    "action": "/create-from-share",
    "method": "POST",
    "enctype": "multipart/form-data",
    "params": {
      "title": "title",
      "text": "text",
      "url": "url",
      "files": [
        {"name": "files", "accept": ["text/*", "image/*", ".text", ".readme""]}
      ]
    }

route can be handled by web server or Service Worker

Quick review of coding Service Workers #

available APIs differ from window
- DOM is not available
- DOMParser().parseFromString is not available
- URL.createObjectURL is not available in a Service Worker
- postMessage to client window, which postMessages back
processing data in Service Worker may lead to duplication of code
easier to just store data until it can be processed in a window
Sharing doesn't appear to count as a user action (transient activation)
testing is tricky — unit tests help, but important parts are inherently outside the browser
handler should return quickly with redirect to an appropriate path — can continue to process in the background

Title, text & url: https://w3c.github.io/web-share-target/demos/sharetarget.html
File, or link and file: https://scrapbook-pwa.web.app/

Can’t share rich text/HTML message
MacOS
- can't directly Create Quick Note
- can't directly Add to Dock
iOS only allows sharing to one precompiled extension per app, it would be difficult to implement the same experience as Android
UWP registration is in app package manifest; not clear how browser can create share target for each app, but support is listed for Chrome, Edge and Opera
Don't hold your breath for more implementations

Long-press on summary in list to share

Notes Together

Summary #

Can be on level playing field with native app, but...
Uneven implementation mean it can't be an essential part of using your webapp
Arbitrary restrictions & uneven support ⇒ must carefully check beforehand if your use case is supported

Gestures in WebXR — Barrier Mage

2021-09-25T00:00:00Z

Slides #

Drawing a symbol #

Root-mean-square #

\sqrt{\frac{(x_{1} - x_{2})^{2} + (y_{1} - y_{2})^{2} + (z_{1} - z_{2})^{2}}{3}}

used to calculate difference between drawn endpoints & template endpoints

Barrier Mage basic play #

Download the MP4 video.

The ELK Stack

2020-01-02T00:00:00Z

talks delivered to technical & non-technical audiences at nChannel in January 2020

technical talk on ELK stack #

A RESTful API on top of the powerful Lucene search engine

document-based search engine (store denormalized data)
JSON + Date, Binary, Range, IP address, Geo-point, shape, etc.
schemas not required, but usually desirable; schema changes rarely break requests
inverted index
weaker storage guarantees than a database; not designed to be a source of truth

structured queries, fuzzy & full text queries, and complex queries that combine the two’

analytics use same indices and are likewise fast

JOIN before ingestion (or in application); can do pre-specified parent-child relations

close integration with Kibana for management, visualization, machine learning

Logstash for server-side data processing

enrich/flatten data (e.g. from ID to full records)
Swiss Army knife
could write to other stores like S3

Beats for client-side single-purpose data shippers

Filebeat: tail file
Metricbeat: metrics like CPU
Packetbeat: network traffic
Winlogbeat:
Auditbeat: replaces auditd, uses same rules
Heartbeat: actively probe systems
Functionbeat: collect from serverless framework, like AWS Lambda

Ingestion

PUT /indexname/_doc/ID
- POST _bulk
ingestion node (like Logstash but less functionality)
Logstash
Beats

use HTTP Service Action to interface with Symphony

non-technical talk on ELK stack #

relational DB: (for example, Oracle or MySQL)

schemas must be rigid
normalize data (each datum stored once)
easy to update
general purpose - good at mixture of reading & writing
JOIN at query time
have to know exactly what you’re searching for

MongoDB:

schemas can be lax
denormalize data (datum may be stored multiple places)
strong consistency (can be source of truth)
may or may not be easy to update
some JOINs can be done at query time
have to know exactly what you’re looking for
compose.com: if you need any more than five or so indexes on a MongoDB collection, then that collection is a prime candidate for putting into Elasticsearch

Elasticsearch:

schemas can be lax
denormalize data (datum may be stored multiple places)
weaker consistency (should not be source of truth)
updating may be slow or difficult
configure each index for family of queries
JOIN on parent-child, or before ingestion, or in application
great support for fuzzy searches, including full-text search
- products related to the one displayed, but only one from each vendor, weighted toward positively-reviewed and high-margin products
- search for “green” products in name, description, or vendor blurb, but not variant, weighted toward name and description
- find a customer who’s surname is Lee, Lea, Li, Le, Lê or Lý
- Comply with HIPPA by searching documents for number groups that appear to be SSNs
- blog posts and comments that contain some variant of “consumer preference” such as “consumer product preference” or “preference of consumer”
- articles from around May 2005 that mention The Beatles
- search-as-you-type (suggest completions)
- find hotels near a specified point
- consolidate logs from all servers, and use machine learning to look for anomalies

close integration with Kibana for management, visualization, machine learning

Logstash for server-side data processing

Beats for client-side single-purpose data shippers

use HTTP Service Action to interface with Symphony 2020-01-13T20:22:44.054Z

ingesting data into ELK stack

Logstash for server-side data processing

enrich/flatten data (e.g. from ID to full records)
Swiss Army tool
could write to other stores like S3

Beats for (client-side) single-purpose data shippers

Filebeat: tail file
Metricbeat: metrics like CPU
Packetbeat: network traffic
Winlogbeat:
Auditbeat: replaces auditd, uses same rules
Heartbeat: actively probe systems
Functionbeat: collect from serverless framework, like AWS Lambda

template is schema that Elasticsearch will confirm to

Kibana Spaces support different classes of users

JavaScript Service Worker Design Patterns for Better UX

2017-09-20T00:00:00Z

Delivered to ColumbusJS in September 2017

Slides #

Web pages used in talk #

offline app: https://serenenotes.hominidsoftware.com (sucessor at Notes Together)
Is Service Worker Ready

Other resources #

Using Service Workers
tooling: Workbox

“Second Screen” apps with the Connect SDK

2014-09-17T00:00:00Z

Delivered to ColumbusJS in September 2014

Motivation #

“Smart TVs” much less interactive than computers
- one set of preferences per app (typically)
- Search is laborious
- No e-mail/tweet from friend that knows you
“Smart TV” interfaces are clunky at best
Most people in front of a TV have a mobile device nearby

What it’s not #

Screen mirroring (ala AirPlay Mirroring or Chromecast tab mirroring)
Additional display over Wi-Fi
Local Media Streaming (ala Play on Roku or AirPlay streaming)

Development & Testing #

Half a dozen Android or iOS libraries required

Setup takes a day, not an hour, unless you’re already familiar with Android development / iOS development.

Testing: buy hardware for any platform you really care about. Only emulator is webOS TV, and that appears to be buggy.

Compatibility - Mobile OS #

iOS, Android, or Cordova for both.

No announced plan for Windows Phone nor web app (Firefox OS, ChromeOS)

Compatibility - TV OS #

8 platforms: LG webOS, Chromecast, Apple TV, Roku, Fire TV, LG Smart TV ’13, LG Smart TV ’12, DIAL

23 features: Apps, Media, System Controls, TV Controls

Broad support for

Launching app w/ known ID
Throw video from URL
Throw YouTube video (& possibly Hulu, NetFlix)
Throw audio from URL
Throw photo from URL
Throw URL to browser?

Other features may not be available on users' devices.

Demonstrate Connect SDK API Sampler #

Media tab #

Throw photo
Throw audio

Apps tab #

Launch Enyo 2 Sampler

Use Cases #

Game using mobile as tilt controller, e.g. Wii game (TV-centric)
Progress through sequence of videos on tablet, optionally displaying on TV e.g. Reading Bear (mobile-centric)
Run web server on phone, display photos on TV, e.g. Zap Photoshare (mobile-centric)
Multiplayer real-time strategy, displaying player-private info on mobile (joint)
Collaborative editing, e.g. Subethaedit, Etherpad (joint)

UX Positives #

TV apps needn’t depend on awkward TV UI.

Don’t need a large phone to view photos or videos, if you can throw them up on a large display.

Avoid logging in to TV

UX Gotchas #

UI can be good while UX is poor.

[ask who’s on local Wi-Fi] Must be on same Wi-Fi network: Ok for home, work, close friends. Poor for Meetup, meeting at clients.

FireTV & DIAL TVs can only “Launch My app” & beam YouTube. Easy to exclude from list, but leaves user frustrated.

Some games are much easier if you can always glance at the map

Conclusion #

This might be the tipping point where users expect devices to work together (like VCRs and TVs did)
Or maybe it won’t catch on, and companies will re-impose their walled gardens

Connect SDK website

Underlying Technologies #

mDNS
WebSockets
DIAL & Chromecast
Apple TV

Enyo: Yet Another Framework or The Next Step Beyond Dojo?

2012-02-16T00:00:00Z

talk delivered at CAS, the Chemical Abstracts Service of the American Chemical Society

Outline #

Who's it from?

Palm/HP: needed an HTML5 rival to iPad & desktop apps
Scott Miles (architect) & Steve Orvell (team member) were early contributors to Dojo

Why A New Framework?

fast rendering
equally supports mobile & desktop
composition of objects (scalable to large apps & varying screen sizes)
dynamic widget creation
design-tool friendly (April '12)

What is Enyo Not?

not for enhancing web pages; it's a framework for writing web apps
not for older browsers (IE8+, most Chrome/Safari, most Firefox)

Enyo Constructors are simple to write

enyo.kind({
name: "Foo"
})
var f = new Foo();

Subclassing is easy, and doesn't require a new directory.

enyo.kind({
name: "Bar",
kind: "Foo",
newProperty: 42
});

Observation: rendering engines are fast at turning big block of HTML to a DOM, slow to update DOM

only HTML is stub (dependencies handled by depends.js); root object instantiates all others, directly or indirectly
dynamic widget creation is similar to quasi-static widget creation (This style can be used in Dojo.)

Objects interact in 3 ways

creation & deletion
message passing
(visual objects) layout

Message Passing requires

sender has been created and not yet destroyed
receiver has been created and not yet destroyed
channel has been set up and not yet torn down So why not make owner the message passing channel?

Component: Enyo Kind that participates in lifecycle & message-passing

Control: Enyo kind associated w/ 1 or more DOM Elements (like a Dijit), and so participates in layout

Ownership/Containment example:

app
header
radio buttons
scroller
list
ajax

Owners call ordinary methods on their children. Familiar, flexible.

DOM events bubble as usual

Custom Events sent to owners. No addListener machinery -> must check that strings match

PubSub -> Enyo:

Components publish to owners. No subscription to events, just methods.
Since owners don't need to contain children, dialogs can be packaged with the Controls that invoke them.

Example: Date picker

a Control with one DOM Element:

{tag: "hr"}

{className: "sidebar"}

a Control with multiple DOM Elements:

{content: "<ol><li>alpha</li><li>beta</li></ol>"}

a Control with many DOM nodes:

{kind: "HtmlContent", srcId: "myContent", onLinkClick: "htmlContentLinkClick"}

index.html:

<div id="myContent">a lot of HTML...which ends here</div>

a Control from a framework widget:

{kind: "Button", caption: "OK", onclick: "okClick"}

a Control from your agglomeration of widgets:

{kind: "MyControlPanel"}

It's turtles all the way down! (Everything is a Control.)

Why JavaScript alone and no HTML?

building DOM goes faster using innerHTML than DOM methods
build DOM tree all at once
easier to read

panel of Controls same as standard widget -> start with standard widget, replace with custom.
example: ?

Layout: encourages but does not require CSS3 Flex Boxes (not emulated for IE8/9)

Ajax API same as Control API.
Any async API (e.g. WebSQL) same as Control API.
A list shouldn't care whether it's receiving info from a button press, WebSQL callback, or AJAX callback.

Combining With Other Frameworks

orthogonal to module loaders
wrap POJSO w/ thin Enyo facade (manually for now, auto in future). Methods map directly. Custom Events must be added as needed.

Message-Passing
Dojo: Pub-Sub or ?. MUX. Separate objects for separate channels. Stovepiped.
Enyo: Owner. MUX, transform. One object may support multiple channels

[show example code]

Status as of early February 2012:

1.0 (Webkit-only) complete
2.0 (core only)

Module Pattern
Facade Pattern
Mediator Pattern

Loose-Schema Databases and Heterogeneous Data

2011-05-09T00:00:00Z

Delivered to ColumbusJS in May 2011

Slides #

Outline #

need for loose schema
- heterogeneous data: different communities conceptualize "similar" info differently. Users now expect computers to adapt to them, rather than users adapting to computers.
  - music meta-data: pop vs. classical: artist vs. composer+performer+conductor
  - to-do items: due date as floating/julian day number vs. absolute times/timestamp, responsible person vs. associated people, source-code management system
  - medical tests: range of BP values not same as range of blood glucose, systolic must be greater than diastolic
heterogeneous data, homogenous format
- converting to homogenous format generally involves a loss of data, or at least an alteration of data. Contact: title+given+ornamental+family+suffix name -> given+family
- round-trip data to external sources: alteration generates a spurious change notification, losing data is unacceptable
partial solution: shoehorning: text field encoded as CSV, JSON or XML
- DB can't search, only payload
- DB can't enforce relations or business constraints
heterogeneous data, manual union schema
- schema must be updated before new data can be stored
- storage may be inefficient
- works fine for music meta-data, fails for medical tests
SQLite: relational + flexibility
- absent fields don't take up storage; sparse DB okay
- columns have type affinity
- ROWID is integer only, is twice as fast
- single-user
Normalization
- array and object fields violate 1NF (depending on your definition of atomicity)
- still should normalize and selectively denormalize
CouchDB
- written in Erlang for robust concurrent systems; no shared state threading and all data is immutable
- crash-only file is always in a consistent state
- "shared-nothing" clustering,
- RESTful JSON HTTP API + 3rd party client libraries
- stores "documents"; JSON I/O
  - unique ID
  - no fixed schema, no declarative schema, update function can check consistency
- lockless & optimistic: if revision number doesn't match, update fails. Resolution similar to Subversion: client merge, re-submit
- incremental replication, partial replicas possible;
- also runs on handhelds
- queries: only Map-Reduce
  - 1st query against a "view" is slow, but later queries only require incremental updating
  - map phase maps documents to N-dimensional array of keys
  - reduce phase (optional) computes sums, averages, unions, etc over one or more dimensions
  - undone subtasks
    - map: if task, write 1 to each parent key, if undone, write 1 to each parent key
    - reduce: sum of each
DB8
- webOS-only, Palm-Bus access
- similar data model to CouchDB, but must write own connector
- single DB shared by all apps
- backed-up to HP/Palm servers
- multiple devices, one profile: may duplicate data
- Universal Search ("Just Type"): simpler than under Palm OS
- sidenote on good UI: standard kinds use union schema: phone app only searches for contacts with phone number, e-mail app only searches for contacts with e-mail addr
- 3rd party "kinds" may extend multiple other kinds, incl. standard calendar event and contact kinds. Can extend contact with case details for CRM
- supports "webOS Synergy™"
  - separate sources have separate records, app presents merged view
  - Calendar: all day or start & end time
  - Contacts: heuristic identifies same person
- Watches
  - asynchronous message from database to app, indicating change in some subset of data
  - not clear whether enabled by non-relational design
  - enables simpler app design
Mongo DB
- document-oriented: no server-side JOINs; embed documents
- queries: analog of most SQL ops
- map-reduce

Talks by Doug Reeder

WebXR for Web Developers

Slides #

vs. native #

Browser Graphics #

APIs for WebXR #

Performance #

Google <model-viewer> #

Frameworks #

Engines #

Tools for non-programmers #

Development (generally) #

Development Support #

Browser & OS Support #

Quest 2/3/Pro #

Pico headsets #

Vision OS #

Personal Computers #

Android #

iOS #

Linux #

Outstanding WebXR sites #

Live-coding #

Join the Cool Kids — If You're Allowed! — The Web Share APIs

Bio #

Outline #

1974: GUI Copy & Paste #

1996: Palm OS Sharing #

2009: Palm webOS Touch-to-share #

Now: Social Media is king #

Enter the Web Share API (send) #

Small signature, complicated use #

File types Chromium on Android will share #

File types Chromium on Android won't share #

Web Share demo apps #

Web Share Target API (receive) #

Quick review of coding Service Workers #

Web Share Target demo apps #

Can't access full native Sharing API #

App that uses Web Share APIs with fallbacks #

Summary #

Gestures in WebXR — Barrier Mage

Slides #

Drawing a symbol #

Root-mean-square #

Barrier Mage basic play #

The ELK Stack

technical talk on ELK stack #

non-technical talk on ELK stack #

JavaScript Service Worker Design Patterns for Better UX

Slides #

Web pages used in talk #

Other resources #

“Second Screen” apps with the Connect SDK

Motivation #

What it’s not #

Development & Testing #

Compatibility - Mobile OS #

Compatibility - TV OS #

Demonstrate Connect SDK API Sampler #

Media tab #

Apps tab #

Use Cases #

UX Positives #

UX Gotchas #

Conclusion #

Underlying Technologies #

Enyo: Yet Another Framework or The Next Step Beyond Dojo?

Outline #

Loose-Schema Databases and Heterogeneous Data

Slides #

Outline #

Software referenced #