2007-09-26 10:52 UTC
A low-bandwidth, high-latency, high-cost, and unreliable data channel
I like food, and I'm not really good at the creative art of cooking (though I'm a fine sous-chef), so I eat out at restaurants a lot.
I usually pay by credit card. In the US, waiters have a minimum wage below the normal minimum wage, and thus you always have to
tip, and so you never pay what the bill says (and I usually tip
well, unless the service or food was appalling, even outside the US).
The net effect of this is that you basically get to decide how much you pay. Indeed, credit card bills at restaurants have a space where
you fill in how much you want to pay.
I don't like doing arithmetic, especially not of the kind "$85.47 * 1.17", and so I just approximate. $85.47 is about $90, 15% of $90
is about 15, round to down to cancel out the earlier approximations gives about $100. So I pay $100.00 and go on my merry way.
One day I looked at my bank statement and it was something like:
POS Trans ZIBIBBO PALO ALTO CAUS
$76.00
POS Trans CHEESECAKE PALO ALTO CAUS
$40.00
POS Trans OUTBACK #0514 CUPERTINO CAUS
$210.00
POS Trans BROOKFIELD'S REST #2 SACRAMENTO CAUS
$34.00
Look at all those zero cents... there are data bits there, lying unused! It struck me that with every single restaurant transaction I
could set the cents field to some number under my control, thus allowing me to communicate with myself at a later date!
This would be really useful as a way of sending ratings information back to myself, so that I could later review the restaurants online
or otherwise keep track of where I would want to go back to or where I would want to avoid (since I eat out a lot, restaurants somewhat
blend together in my memory).
We can set any number from 0 to 99. In binary, that's 0b0000000 to 0b1100011. In other words, we have seven bits to play with, except that if both of the high bits are set, then we lose bits 3, 4, and 5.
There are five things I wanted to be able to communicate. The first was the number of guests, so that I can divide the price by how many
people I was paying for, to determine the price-per-person. The second was the rating, whether I should go back or not. The last three were
whether the restaurant had wifi, whether they were suitable for vegetarians (Carey
is vegetarian), and whether they had drinks I liked (I don't drink addictive drinks, drinks containing mind-altering drugs, carbonated
drinks, and drinks containing high fructose corn syrup, which basically excludes almost anything you can buy in the US in many cheap
restaurants, and even some fancy ones).
If we consider the rating to be a four-state flag, with values "avoid", "ok", "good", "awesome", and if we limit ourselves to being
able to specify 0, 1, 2, or "more than 2" guests (in addition to me), and if we establish that if we want to avoid the place in future then it really doesn't matter whether the restaurant
had Internet, a vegetarian selection, or good drinks, then we can neatly fit this into our
contstrained not-quite-7-bit bitfield like this:
64
32
16
8
4
2
1
r
d
v
i
g
...where:
r
The rating, according to the following scale:
0
awesome
32
good
64
ok
96
avoid (and ensure d, v, and i are set to 0)
d
Whether drinks are good or not (set means they are good)
v
Whether a vegetarian selection is available (set means there are vegetarian options)
i
Whether free wifi Internet access is available (set means wifi is available)
g
How many guests were paid for in the transaction:
0
just me
1
me and one guests
2
me and two guests
3
me and three or more guests
I did this, and used it for a while. I quickly discovered that something was wrong. The numbers in my bank statement made no sense, for
example dinners with more than 2 guests at locations where I knew that I had been with just one person.
I changed to a new scheme. Instead of encoding data in the cents field, I instead just store the last two digits of the dollar amount
into the cents field. A checksum, if you will. So if it cost around $34 with tip, then I put $34.34, or if it cost $122, then I put $122.22.
I do this reliably now, on all restaurant transactions.
What I've found is a shocking number of restaurants don't charge me what I write. For a while I thought I just had bad handwriting, but I
then went out of my way to write very clear numbers and that didn't help. For example, Zibibbo's in Palo Alto. I remember very clearly writing
$77.77, but was charged $76.95. That's not the original amount without tip (which was probably closer to $65), it's not what I wrote, what the
heck is it? On the other hand, the other time I went, they charged me $865.65, exactly what I wrote. A cafe in Monterey (Portola Cafe)
charged me $18.28. Either they charged me ¢10 too much, or they gave me a $10 discount. The Melting Pot, San Jose, charged me $70.54.
Where did the .54 come from? Why not take the remaining ¢16? Pasta Pomodoro did the same trick as Portola, charging me $37.47. But two
months before that, they charged me $34.31, which is probably ¢3 less than I wrote. Why am I
getting overcharged sometimes and undercharged others? In Hawaii, the majority of restaurants ignored the tip altogether, just
charging me the original amount regardless of what I wrote. Are people in Hawaii so relaxed that they don't need the extra money from tips?
My theory is that it is because I don't write an explicit tip, I just give the total. Maybe restaurants need the tip as well as the total,
and so to save time they just work out a round dollar tip that is close to what I wrote, and charge me that. My next step, to test this theory,
is to start always writing the actual tip amount in.
Somewhere over the rainbow,
Way up high,
There's a land that I heard of
Once in a lullaby.
The explosion during the man's burn was quite the surprise, but
I'm glad they delayed the derrick's burn until after the man because
otherwise the man would have been a non-event in comparison. Holy Hannah.
This year wasn't quite as enjoyable as last year, but mostly that was
just because of the weather: I didn't get to go around the deep playa and
jump on art cars as much as I'd have liked.
Somewhere over the rainbow
Skies are blue
And the dreams that you dare to dream
Really do come true.
While I was away, late last week, while nobody was looking at the #whatwg channel,
and in stark contrast to the Burning Man atmosphere, someone visited and asked a
question which went unanswered. The log went like this:
--> Nicklas18 (i=Nicklas1@c-f54ce155.28-2-64736c13.cust.bredbandsbolaget.se) has joined #whatwg
<Nicklas18> Why leave the sense of logic at the door?
<Nicklas18> Does that mean that you are not logical?
<Nicklas18> Shouldn't people in charge of making a standard have common sense?
<Nicklas18> Hello?
<Nicklas18> Fucking retards.
<Nicklas18> Suck my huge cock.
<-- Nicklas18 has left #whatwg
(The /topic in the #whatwg channel says "Please leave your sense of logic at the
door, thanks!", for reasons that should be obvious to anyone who has tried working
with Web browsers for more than about 5 minutes.)
The sun is shining,
It's a lovely day,
A perfect morning
For a kid to play,
Carey and I have now seen Avenue Q twice, once on Broadway and once in San
Francisco. I love this show. Everyone should see it.
The internet is really really great.
I’ve got a fast connection so i don’t have to wait.
There's always some new site;
I browse all day and night;
It's like i’m surfing at the speed of light.
Work on HTML5 progresses at a measurable pace — literally, now, since I'm
measuring the number of e-mails I have outstanding on a regular basis to determine how
well I'm hitting my quarterly targets. (Answer: Not as well as I'd like, but not as
badly as I'd feared.) As a side-effect of writing the code to trawl my IMAP folders to
count the outstanding e-mails, I wrote a tool
that also exposes the folders on the Web (after having filtered out the
confidential feedback I get, of course). I was hoping this would address some of the
complaints about lack of transparency, and indeed a number of WHATWG contributors were
interested, gave helpful feedback, and even wrote their own frontends using the tool's
APIs. However, from the W3C corner of the HTML5 communities I only got complaints. The
most notable complaint was that the tool didn't work in IE, which was apparently a
problem not because it actually stopped anyone from accessing the page (I haven't
received any complaints from anyone who actually couldn't get to the page) but because
it might potentially stop users of old accessibility tools that only work
with IE from accessing the page.
When you help others,
You can’t help helping yourself!
Every time you
Do good deeds
You’re also serving
Your own needs.
I've actually been using the latest version of JAWS (the popular Windows screen
reader software for blind people) recently, as part of my work on HTML5. From a
usability point of view it is possibly the worst software I have ever used. I'm still
horrified at how bad the accessibility situation is. All this time I've been hearing
people worried about whether or not Web pages have longdesc attributes
specified or whatnot, when in fact the biggest problems facing blind users are so much
more fundamental as to make image-related issues seem almost trivial in
comparison.
For example, JAWS will happily take the last sentence of a paragraph, and the first
sentence of the next paragraph, and run them into each other as one sentence, if
there's no full stop at the end of the first paragraph. If you really want to make
your Web pages more readable to blind users, forget longdesc or even
alt, or even markup of any kind, just make sure you're using full
punctuation! And that's just one example. Browsing the Web with JAWS is a horrifying
experience not because of the poor state of the Web, which is admittedly very poor
indeed from the point of view of semantic and accessible markup, but because of the
terrifyingly poor state of the screen reader software.
What might make my experiences with JAWS even more worrying is that I'm told JAWS
is amongst the best of the available screen reader software. It certainly isn't worth
its ridiculous $895 price tag (let alone the $1095 price tag for the "professional"
version I got). There is a big market opportunity here for someone to make a usable
and affordable native speech Web browser or screen reader. Accessibility advocates
could do more for accessibility by writing test suites for screen readers to check
their basic HTML support (like supporting the p element) than they ever
will by trying to educate Web authors.
What do you do with a B.A. in English?
What is my life going to be?
Four years of college and plenty of knowledge
Have earned me this useless degree.
Going back to my earlier comment, though, I'm a little confused as to why several
people who have joined the HTML5 community from the W3C HTML WG side are so hostile,
while those who joined the community through the WHATWG side are so much more friendly
and constructive. A couple of weeks ago I had to temporarily ban someone from the
WHATWG list after they repeatedly cross-posted an off-topic flamewar to four mailing
lists including the WHATWG list. (They didn't get banned from the other three lists as
far as I know.) I was really sad about having to do this, but the health of the
community is important, and sometimes extreme measures have to be taken. This is the
first time I've had to do that to someone on the WHATWG list, and the list has existed
since 2004. (I've set up personal mail filters for people on the WHATWG list before,
to ensure that I read certain people's suggestions only once I've read all the other
mail, but I've never had to actually ban someone.)
The HTML working group is having a meeting in November. I don't really see the
point, but as I told Dan (the chair of the working group), if we do have a meeting,
I'd like us to use the unconference style, as that's probably the only useful thing we
could do.
Hopefully we'll have the agenda this week, that way I can know whether I can
justify going or not. I can't really justify spending Google's money on travel, let
alone justify the carbon emissions and the time away from editing the spec, without
knowing what exactly the meeting will consist of. If the meeting just consists of us
going through open issues and discussing them, then I won't go, since in my experience
that's a huge waste of everyone's time unless the issue has already failed to be
addressed by more asynchronous methods like e-mail. For technical work like this you
really need to be able to sit down and think about issues, and ponder them with a
whiteboard; it is very hard to make sure all the applicable research has been done
when there is pressure to discuss and reach a decision on a topic in 60 minutes or
less. This is especially true since for almost all issues, the first time you look at
it you'll find many things you need to research, and it can take days to get all the
data you want to make an educated decision.
Using actual data to make decisions about technical issues isn't a very
common practice in W3C working groups, which is probably why a lot of the people in
the HTML working group who come from a W3C background think a face-to-face meeting is
a useful thing to have.
I want you to know
The time that we've spent
How great it's been
How much it's meant.
The Falcon Ridge Folk Festival has a sign language interpreter on every stage. Now
mind you, this is a music festival, a specifically sound-orientated event.
Yet it is highly accessible; all the songs have alternative fallback content for those
who cannot hear them. There are several things about this that I noticed.
First: The visual version of the song (lyrics in sign language, and the emotional
content of the voice, expressed in the facial expressions and style of the sign
language interpreter) doesn't convey the same thing as the original audio version (the
melody, the harmony, the percussion, the lyrics, and the emotion in all of those). It
is merely a translation of the parts of the audio stream that aren't intrinsically
audio-only. Alternative content doesn't necessarily convey everything in the
primary medium, nor does it have to to be useful and enjoyed by the target
audience.
Second: The sign language interpretation is actually quite fun to watch even if you
can hear the music, it's like a kind of interpretative dance. Alternative
content is useful to those who don't need it as well.
This isn't just my opinion. It was clear at the festival that the sizeable deaf
community present there was fully enjoying the music. The presence of sign language
interpreters made them feel part of the event, and conveyed everything that they
wanted conveyed. Meanwhile, the hearing patrons enjoyed the music and the
sign language — I heard comments from several people to the effect that the sign
language interpreters were effectively an intrinsic part of the act. (To the point
where even people who didn't necessarily understand sign language had opinions on
which interpreter was better.)
It's interesting how the prevailing opinion of Web accessibility experts is so far
removed from the existing and successful accessibility practices in the non-tech
world.
It came to my attention while I was cycling to Bab5 tonight that not all drivers of big cars may be fully aware of the meaning of this device sometimes found near intersections:
For the purposes of making sure drivers in the area are well educated, I would like to clarify the meaning of this device. It means "stop". That is to say, "do not turn left onto oncoming traffic".
Back in March, Google hosted the CSS working group for a three day
meeting.
At the time, we were just starting with the HTML working group, and
the openness of the WHATWG over the past few years was just starting
to be adopted by the HTML working group, after several months of
pushing for it in the W3C (mostly in secret, though myownpostsonthe
matter were all public, as were a
fewothers).
One of the things I brought up in the CSS face-to-face meeting was
the problem of the CSS working group not being open. Many of the
members of the CSS working group have a mentality that view the Web
community (such as those who e-mail the www-style
mailing list) as a resource, not as potentially equal members
of the community. Of the forty or so members of the working group
(those subscribed to the secret internal mailing list), only a dozen
subscribe to the public list. This actually makes it harder
for members of the group to try to be more open — when someone
posts a proposal to the public list, there's a good chance that the
majority of the members of the working group will miss it. During the
meeting, I opined that if the group continued along in this direction,
the group ran the risk of becoming irrelevant; two of the other
members suggested that the group was already
irrelevant. Sadly we were in the minority.
The CSS working group right now is chronically dysfunctional, as
most close observers have noticed.
A great example of this is the difference in how the WHATWG got a
blog and how the CSS working
group set one up. In the WHATWG, the idea was floated for a while, and
then one day someone volunteered
to run it, and the blog was up and running within hours. Anyone
(literally anyone) can post to the WHATWG blog (there's a moderation
step that we added to deal with the spammers, but all it takes now is
to get onto IRC and ask
for the post you wrote to be published). The CSS working group, on the
other hand, has been discussing how to set up a blog, and what the
first entry should say, and what tool to use, for over two
months! Nearly every phone call (the group has weekly
teleconferences) for the past nine weeks has had the blog discussed at
some point.
The blog was finally made
available last week. To post, you have to be a group member. The first
post can be summarised as follows: the CSS working group members
don't want to bother going out of their way to get feedback on their
specs; instead, people should post their comments on CSS to the public
CSS mailing list (despite the fact that most CSS working group members
aren't subscribed to this list). The blog post then goes on to
apologise for the blog's existence, and claims that the blog's aim is
to reach the people who won't subscribe to the public mailing list
(the working group itself, maybe?). The post doesn't make it clear
how the blog is expected to reach this wider audience, since
the blog has no comment feature.
Another example of the problems of the CSS group is visible on the
W3C's Technical Reports page. The
group's primary deliverables are specifications. The last candidate
recommendation published by the group was published in 2004. That was
the Basic UI module, which
was Tantek's baby (he has since left the group). Meanwhile, drafts
like the Backgrounds
and Borders draft, which has had big parts implemented by Safari
for months, and small parts implemented by Mozilla for years, have
iterated several times but make no public process (the backgrounds and
borders draft was published in 2005, but the internal draft was last
modified in February of this year).
Meanwhile, CSS2.1, the working group's most important deliverable,
keeps getting tied up, with the group discussing irrelevant details
and some members repeatedly reopening old resolved issues. The W3C
process doesn't help much here either; the group actually tried taking
CSS 2.1 to Candidate Recommendation stage recently, but was blocked by
the W3C management over an issue which was already present in
CSS2. (In all fairness to Tim, the issue he
raised is one which was already raised by several other people, but
which the group had dismissed. I actually agree with him that it
should be resolved. The group has since resolved to change the spec in
a way that continues to leave the issue undefined, but at least it no
longer contradicts what Web browsers do.)
The group is also supposed to work on test suites. I had
volunteered to work on the CSS 2.1 test suite, but due to lack of
time, I bailed on that last year (Google mainly employs me to work on
HTML5; any test work that I do is done in my free time, which is
mostly spent near aquariums now). Since
then basically nothing has happened.
Being public would expose a lot of these problems, forcing the
working group to act more responsibly. It would also allow people to
contribute — as specification editors, as test suite editors, as
reviewers, as community leaders, and in other roles.
But to be honest, the problems go even further than what I've
described above.
The CSS specs show their age; they come from a time where
specifications were much vaguer than those of the modern day. Someone
really needs to do to CSS what the WHATWG has been doing to HTML,
defining everything in detail, explicitly, with strict and clear
normative conformance criteria, taking implementations into account,
defining things like quirks mode. (The WHATWG community refers to such
a hypothetical project as "CSS 5", as a reference to the way the
current WHATWG specs define HTML5, XHTML5, and DOM5 HTML.)
The CSS working group also doesn't really have the nimbleness
needed to respond to threats to the Web platform like Silverlight. We
need things like flowing-to-shapes, automatic declarative transition
animations, gradients, filters, styling of form controls, and so
on. (The WHATWG is already handling some related, non-presentational,
things, like client-side
SQL databases, video,
and richcontrols.)
We need these things this year, in enough detail that they
can be implemented. An open group can iterate much faster than a
closed group. With an open group we can get test implementations,
feedback, tests, and discussion straight away, instead of waiting
months and then pulling back the curtain and presenting a fait
accompli, at which points comments are perceived more as a pain
than a help.
One way to address this would be for the WHATWG to start a
"subproject" to address CSS, while we wait for the W3C CSS group to
learn from the W3C HTML group and become open. The biggest problem
would be finding editors who would be willing and capable of
doing the incredible work of rewriting CSS from scratch.
