demo – Terence Eden’s Blog

Gadget Review: 6-Colour ePaper Name Badge ★★★★⯪

@edent — Sun, 20 Apr 2025 11:34:47 +0000

The good folks at SmartDisplayer Technology Co have sent me a six colour eInk badge to play about with.

Here's a quick video and then a walk-through of its features.

You can also view SmartDisplayer's official video.

The Badge

It is a single block of plastic. There are no seams, screws, or rough edges. The ePaper appear right on the surface of the badge, there's no recessing or anything to indicate that this is a high-tech gadget. It uses their "cold lamination" technology which creates an impeccable matt finish.

The display area is 56.4mm x 84.6mm - which is pretty close to the size of a standard credit card - for a resolution of 180PPI.

The eInk

This uses E-Ink Spectra 6 technology. With only 6 colours to play about with there's a lot of dithering needed to make a picture look presentable. Those 6 colours are:

#000 Black
#F00 Red
#0F0 Green
#00F Blue
#FF0 Yellow
#FFF White

I used a standard Monitor Calibration Image, dithered it using the supplied software, and flashed it to the card. I then scanned in the card so you can see exactly how faithful the image reproduction is.

On the left, the eInk. On the right, the original image.

That's pretty bloody good!

Using Bruce Lindbloom's RGB Reference image is also a good way to test a range of colours.

Not bad for red, green, blue, yellow, white, black, eh?

It's hard to find a good test-card with a variety of skin-tones (there's a creepy Getty one with naked women), so I used the Murideo Portrait Reference Photograph. The original:

On eInk:

And here's another one:

The Card Writer

For Linux nerds, the USB writer showed up as: 1fc9:0102 NXP Semiconductors IT-102MU Reader.

There's almost no information about it other than a brief discussion on an OpenBSD mailing list, and a mention on the CCID database. Apparently it will work as on ChromeOS. It makes a hideous beeping sound when the card is inserted.

Once the card is inserted, two LEDs light up.

The green one quickly vanishes, but the blue one pulses until the card is removed from the reader.

Detailed lsusb Output

How to password protect a static HTML page with no JS

@edent — Mon, 20 Feb 2023 12:34:34 +0000

I recently saw Robin Moisson's method of password protecting a statically served HTML page. It's quite neat! But it does rely on JavaScript. That got me wondering if there was a way to encrypt a static page only using CSS?

And... I think I've done it!

I'll warn you now, this is a deeply stupid way to solve the problem.

Here's a screencast of the demo in action:

https://shkspr.mobi/blog/wp-content/uploads/2023/02/fucking-stupid-css-encryption-lol.mp4

Type the password and the page decrypts!!!!!

This abuses some interesting CSS features.

First, you can display the

Secondly, you can make the CSS editable by the user with contenteditable

As soon as a user types into the CSS, it is applied to the page. No need for JS.

So if a user types in a password...?

Let's step back a bit. How can we encrypt text using CSS? I know... WEBFONTS!

A WOFF2 webfont is a Brotli compressed file. If I've read the spec correctly (LOL!) removing a chunk of a small file should render the file too damaged to read.

It's possible to convert the WOFF2 into Base64 and use it in the CSS:

@font-face {
   font-family:'encrypt_sans';
   src:url('data:application/font-woff2;charset=utf-8;base64,d09GMg...') format('woff2');
}

Cut a chunk out of the middle of that font, and use that missing piece as the password. Foolproof!

But - I hear you say - how to encrypt text using a font? Well, that's easy!

That cleverclogs Eli Grey has a font which encrypts text. It's magical. Well, OK, it's ROT13. Obviously, any substitution cipher can probably be broken using frequency analysis.

Of course, it is possible to use font ligatures to obfuscate the text even more. See Bullshit Sans as an example

So, there you have it. A way to sort of encrypt a statically served HTML file without using JavaScript.

Demo and Source

Demo
Source

Possible Improvements

This was a demo hastily put together while hungover one weekend. There's lots of room for improvement.

The UI abuses CSS to hide some of the boilerplate involved. It could be made to look nicer.

There's no way to generate an "encrypted" font. Ideally someone (not me!) would take a plaintext and generate a scrambled and ligatured font to automagically do this.

It is inaccessible to screen readers. The font doesn't change the underlying text.

Brotli compressed WOFF2 files might be recoverable even after substantial damage.

This is really really stupid.

Better Keyboard Buttons in CSS

@edent — Sat, 30 May 2020 14:39:05 +0000

Here's a simple scrap of CSS which you can Ctrl+C and Ctrl+V

kbd {
    border: .1em solid #aaa;
    border-radius: 15%;
    display: inline-block;
    padding: .1em .5em;
    background: linear-gradient(180deg, #fff, #fff, #fff, #ddd);
    user-select: none;
    cursor: pointer;
    color: #000;
    font-weight: bold;
}
kbd:hover {
    background: linear-gradient(0deg, #fff, #fff, #fff, #ddd);
}

Features

Semantic use of the kbd element
Uses em to ensure it is consistent with the font size of your document
Text of buttons is not selectable
Cursor will change to a pointer when hovered
"Push" effect when hovered

Unicode Buttons

Apple command ⌘
Apple alt ⌥
Enter ⏎ or ↵
Backspace ⌫
Shift ⇪
Escape ␛
Tab ⭾

How to present at a hack day

@edent — Thu, 07 Nov 2019 12:46:46 +0000

I go to lots of hack days and hackathons. Some are big corporate affairs, some are boutique community events. They all have one thing in common - Geeks suck at giving demos.

You have 3 minutes to convince the judges - or your peers - that you've built something brilliant. How do you do that?

One Hundred and Eighty Seconds. It is not a lot of time. So here are my top 3 tips for succeeding at a demo.

Show the thing

This is the most important one. You need to show what you built. Demonstrate the thing that it does and what's clever about it.

The audience gets death-by-powerpoint every day at work. A good demo won't bombard them with slides.

Even worse, is a presenter who spends all the time talking about the problem, discusses their build environment in great detail, then runs out of time to do the actual demo.

I've literally seen someone spend two and a half minutes talking about why they hate Heroku and how they swapped to AWS - only to realise they have no time to show anything.

Here's my brief guide to showing the thing:

Take 10 seconds at the start to explain the premise behind your app as simply as possible.
- "I wanted to build an X, using Y, to fix Z."
- That's really all you need to say. Your demo should fill in the gaps.
Show the happy-path through the app. No one cares if your demo does password validation.
- "When you open the app / website it shows you a thing. When you click on the thing, it does this clever thing."
At this point, you can talk about the technology.
- "It uses BlipSoft's AI library to talk to Funkenstien's middleware layer. We built a converter to recalcify the bytes."
Show one or two other clever bits.
- If the user uploads a picture of a cat, the interface dynamically changes to be cat themed!"
Don't tell people what doesn't work.
- If it can't handle photos of dogs, or if it crashes on a Tuesday, or if it only works on landscape Android phones running a bodged firmware... so what? This is a quick hacky demo. You don't need to martyr yourself.
Have a definite ending.
- "Thank you for watching! Any questions?"

And, you do need to demo something. Some PowerPoint slides are not a demo.

Keep to time.

This is also the most important tip. If you run over time, you're being rude to the audience and to the other presenters. The judges will not thank you for it.

You have a limited time - and that should be fine. You shouldn't build something in a weekend that takes more than a few minutes to demo.

Actively work to make your product quick to use. In these days of engagement metrics, it's hard to remember that your user probably doesn't want to spend much time using your product.

Here's a bad example I saw recently. The team had built a nifty AI demo which looked at a photo and gave back useful information. They'd built this into a chat-bot. And that's where things went wrong.

The demo they gave looked like this:

Bot: Hi! I'm Botso! Your vision companion! What's your name?

The presenter then typed "Hi Botso, I'm Jane. Nice to meet you."

Bot: Great to meet you too, JANE. Would you like to upload a photo?

The presenter then typed "Yes I would."

Bot: Cool, JANE. Your photo must be smaller than 4MB and be JPEG. Is that OK?

The presenter then typed "I only have a PNG."

Bot: Never mind JANE, I'll convert it. Click here to upload

All of that preamble might be good in a production app - but for a demo you can skip straight to the good stuff.

Rehearse.

So how do you succeed at the first two points? The same way you get to Carnegie Hall.

About two hours before the demo, stop coding. If you add anything new now, I guarantee you're going to break something.

Start a timer on your phone, turn the phone over, then give the demo. You have to actually speak the words aloud - not just in your head. Click through the thing you're demoing. When you reach the end, flip your phone over again and see how long it took. My guess is your idea of 3 minutes is different to the stopwatch's idea.

Work out what you can trim from your demo? Do you really need to explain your git branching strategy? Can your demo already be logged in rather than waiting for a 2FA SMS? Will the audience care about something you spent ages on?

If anything is seriously broken with your demo, fix it. But remove the temptation to add any new code or to change any of the outputs.

Go to the room where presentations will be taking place. Is there a stage? Is there a microphone? Does the WiFi work there?

In the half hour before the presentation, you and your team should run through your presentation repeatedly.

Stand up while you rehearse. Practice passing the microphone to each other. What will you do if a bit of the demo fails? Are you consistently finishing in under 3 minutes?

Isn't this a bit much?

Yes, possibly. I'm a bit obsessive about good demos. Brilliant technology is often hidden because of a crap demo.

Communicating ideas is an important skill. If your app cures cancer, but you spend 3 minutes talking about how hard a specific API is to use, no one will understand its importance.

If you only take one piece of advice from this blog post - just rehearse your demo a few times before going on stage. I see too many presenters who are genuinely shocked at how quick 180 seconds go by.

Your hacks are amazing - and you deserve to show them off in their best light.

Demoing BlipDrop at Mobile Monday London

@edent — Wed, 11 Sep 2013 16:01:15 +0000

This is a necropost - resurrected from the now defunct blog of a previous employer. I really loved the idea of geolocated ephemeral content. And I was a little disappointed that the business never saw the potential for it. Maybe I'll find a way to relaunch it in the future.

I’ve been attending Mobile Monday London for years. It’s a great (free!) way to meet people in the mobile industry, to learn about new trends, and to demo products.

Because I know so many people there, it’s always a bit nerve-wracking when I stand up to demonstrate some crazy new idea. Obviously I crave the approval of my peers but, more than that, I don’t want to look like an idiot in front of my friends.

On Monday, I gave BlipDrop its first public demonstration at Mobile Monday Demo Night. We’ve been running for a couple of days with a closed group of 10 beta users so I was eager to see what people thought of it.

I can really recommend getting involved in Mobile Monday. They offer some great free talks, and provide excellent opportunities for new and established businesses.

Massive thanks to Julia Shalet for all her organisational skills, and to Jo Rabin for being such an effective host – indeed, the whole team put on a fantastic event.

Optical Theremin - Demo

@edent — Sun, 10 Jun 2012 15:08:49 +0000

At Over The Air I demonstrated what I considered a novel use for one of Android's sensors. I wanted to create a Theremin - a type of musical instrument which is played by moving one's hand over it - changing pitch and tone by moving nearer or further away.

My first attempt used the proximity sensor. However, on all the Android phones I tried the sensor's accuracy was binary - it could sense if something was close by, but not say how close.

So, what else could I use to detect how near or far a hand was from the screen? I decided to co-opt the Light Sensor. This is normally used to automatically adjust the brightness of the screen - making it easier to see in strong light.

When the light sensor is uncovered, the total lux (that's the measure of light) may be 100. As a hand moves closer to it, that value will dip until it reaches 0 (or, on my phone, 4).

We can then represent that light value as a sound - essentially transforming lx into Hz!

This is what is sounds like

Your browser does not support the audio element - download the track.

Beautiful, I'm sure you agree! You can hear an interview where I discuss this app with the BBC's Jamillah Knowles on the Outriders Podcast (22m 50s in).

🔊 Outriders 05 Jun 12: Moscow and Bletchley Park
🎤 BBC Radio 5 live

💾 Download this audio file.

If you want to have a play with it, the Optical Theremin Demo is in the Google App Store. Do note, it was coded in a couple of sleep deprived hours, crashes when you exit, and can produce "music" which scares children and animals. You have been warned!

Use The Source, Luke!

I've included the full source below, but I'd like to pick out two points which may be of interest.

Getting The Lux Value

Firstly, we need to register a listener for the light sensor.

@Override public void onCreate(Bundle savedInstanceState) {
   super.onCreate(savedInstanceState);
   mSensorManager = (SensorManager) getSystemService(SENSOR_SERVICE);
   mLightSensor = mSensorManager.getDefaultSensor(Sensor.TYPE_LIGHT);
   mSensorManager.registerListener(this, mLightSensor, SensorManager.SENSOR_DELAY_FASTEST);
}

Every time the light sensor changes, this method will be called. It takes the light value and performs a simple mathematical transformation on it (adds 10, multiplies by 5). I found that this gave the most pleasing sound - but you can adjust it to your tastes

@Override public void onSensorChanged(SensorEvent event){
   if (event.sensor.getType()==Sensor.TYPE_LIGHT){
       mLux = event.values[0];
       freqOfTone = (mLux +10) * 5;
   }
}

Cum on Feel the Noize

So, how do we get Android to generate a tone? I faffed around with this audio generating code from StackOverflow until I could successfully generate a tone.

Essentially, this creates a WAV of a tone and gets it ready to play.

However, this sounded rather boring, so I added some reverb.

audioTrack.attachAuxEffect(EnvironmentalReverb.PARAM_DECAY_TIME);

And that's it!

Download the Optical Theremin Demo App - or use the source to create something much more melodious.

Full Source

package mobi.shkspr.android.theremin;

import java.util.Random;

import android.app.Activity;
import android.hardware.Sensor;
import android.hardware.SensorEvent;
import android.hardware.SensorEventListener;
import android.hardware.SensorManager;
import android.media.AudioFormat;
import android.media.AudioManager;
import android.media.AudioTrack;
import android.media.audiofx.EnvironmentalReverb;
import android.os.Bundle;
import android.os.Handler;
import android.util.Log;
import android.widget.TextView;

    public class TheraminActivity
        extends Activity
        implements SensorEventListener{
        // originally from http://marblemice.blogspot.com/2010/04/generate-and-play-tone-in-android.html
        // and modified by Steve Pomeroy steve@staticfree.info

        private final int duration = 5; // seconds
        private final int sampleRate = 8000;
        private final int numSamples = duration * sampleRate;
        private final double sample[] = new double[numSamples];
        private double freqOfTone = 440; // hz

        private final byte generatedSnd[] = new byte[2 * numSamples];

        private SensorManager mSensorManager;
        private Sensor mLightSensor;
        private float mLux = 0.0f;
        private String tLux = "Lux is ";

        public AudioTrack audioTrack;

        Handler handler = new Handler();

        @Override public void onCreate(Bundle savedInstanceState) {

            super.onCreate(savedInstanceState);


            mSensorManager = (SensorManager) getSystemService(SENSOR_SERVICE);
            mLightSensor = mSensorManager.getDefaultSensor(Sensor.TYPE_LIGHT);

            mSensorManager.registerListener(this, mLightSensor, SensorManager.SENSOR_DELAY_FASTEST);

        }

        @Override public void onSensorChanged(SensorEvent event){
            if (event.sensor.getType()==Sensor.TYPE_LIGHT){
                mLux = event.values[0];
                String luxStr = String.valueOf(mLux);
                TextView tv = new TextView(this);
                tv.setText(tLux);
                setContentView(tv);
                Random r = new Random();
                freqOfTone = (mLux +10) * 5;
            }

        }
        @Override protected void onResume() {
            super.onResume();
            final Thread thread = new Thread(new Runnable() {
                public void run() {

                    for (int i = 0; i < 300; i++)   {
                        genTone();

                        audioTrack = new AudioTrack(
                                        AudioManager.STREAM_MUSIC,
                                        sampleRate,
                                        AudioFormat.CHANNEL_OUT_MONO,
                                        AudioFormat.ENCODING_PCM_16BIT,
                                        numSamples,
                                        AudioTrack.MODE_STATIC);


                            try {

                                playSound();
                                Thread.sleep(505);
                            } catch (IllegalStateException e) {

                            } catch (InterruptedException e) {
                                // TODO Auto-generated catch block
                                e.printStackTrace();
                            }
                    }
                }
            });

            thread.start();
        }

        void genTone(){ // fill out the array
            tLux = "Frequency is " + freqOfTone;
            //Log.d("LUXTAG", "Lux value: " + tLux);

            for (int i = 0; i < numSamples; ++i) {
                sample[i] = Math.sin(2 * Math.PI * i /(sampleRate/freqOfTone));
            }

        // convert to 16 bit pcm sound array
        // assumes the sample buffer is normalised.
            int idx = 0; for (final double dVal : sample) {
                // scale to maximum amplitude
                final short val = (short) ((dVal * 32767)); // in 16 bit wav PCM, first byte is the low order byte
                generatedSnd[idx++] = (byte) (val & 0x00ff);
                generatedSnd[idx++] = (byte) ((val & 0xff00) >>> 8);

            }
        }

        void playSound(){
            genTone();
            try {                   audioTrack.attachAuxEffect(EnvironmentalReverb.PARAM_DECAY_TIME);
                audioTrack.write(generatedSnd, 0, generatedSnd.length); audioTrack.play();
            } catch (IllegalStateException e) {
                audioTrack.release();
            }
        }

        @Override
        public void onAccuracyChanged(Sensor sensor, int accuracy) {
            // TODO Auto-generated method stub
        }

        @Override
        public void onPause() {
            super.onPause();
            audioTrack.stop();
            audioTrack.flush();
            audioTrack.release();
        }

        @Override
        public void onStop() {
            super.onStop();
            audioTrack.stop();
            audioTrack.flush();
            audioTrack.release();
        }

        @Override
        public void onDestroy() {
            super.onDestroy();
            audioTrack.flush();
            audioTrack.stop();
            audioTrack.flush();
            audioTrack.release();
        }
    }

QRpedia Demo at Mobile Monday

@edent — Wed, 20 Apr 2011 06:02:21 +0000

I love going to Mobile Monday London - it's a great meeting place for those of us in the mobile industry. It's also one of the few spaces which holds the equivalent of an "Open Mic" night. MoMoLo's Spring Demo Night was crowded with great entrants. So much so that each of us had only three minutes to present! That's quite tight. I'm used to 15-30 minutes. I'm not sure how, but I managed to distil the QRpedia pitch down.

QRpedia was received warmly by the crowd. Massive thanks to the ever-patient Liz for recording it.

Don't just take my word for it - here's a sample of tweets from the evening.

https://twitter.com/c1rrus/status/60041453216346112

We also had a lovely write up from Ged Carrol

QRpedia was less of a business and more of a duh why hadn’t anyone else thought of putting QRcodes more effectively with Wikipedia.

So, onwards and upwards. I'll be getting in contact with the journalists who approached me to see if we can get some favourable press. I'm also talking to people who might be able to sponsor free WiFi in museums to reduce the cost for international tourists.

Any questions - drop them in the comments box.