Rest Resource Granularity

ASCII Infographics

Client                     REST
Convenience - <---------- Resource ----------> + Cache-ability,
                         Granularity             Chattiness
I think Infographics are too 'pretty'. Long live ASCII Graphics!
Tagged API

Using Unicode To Increase Information Density in Tweets

Quite a while back I grabbed the twitter handle @pdxweather with plans to broadcast the local weather over it. I first thought I would send out a daily broadcast for today's weather and tomorrow.  Being Portland, Oregon, I'm centering around the "Chance of Rain" for those days at least as a starting point. This has proven to be quite a challenge to accomplish with 140 characters. The technology needed to produce such tweets is not all that difficult.  I built a little PHP script that would parse the forecasts from form the weather.gov API.  I then have a PHP script that builds a short summary of that information and tweets it (once a day at this point). http://twitter.com/pdxweather

Attempt 1:

Sun_18th:light rain precip%day:13 precip%eve:29 Mon_19th:light rain precip%day:53 precip%eve:64 (NOAA splits the % chance of rain to day and eve.  I like this feature so I want to have that in the tweets also even though it makes it that much more difficult to stay under 140.) Lots of room for improvement here.

  • Hard to see the dividing line between the days
  • Not even showing hi/low temps yet and we are at ~95 char so longer weather descriptions (i.e. "Light rain and high wind warning"") along with temps could easily put us over 140
  • Overall, it's just hard to parse out the individual bits of information

Attempt 2:

Goals:

  • Reduce the overall character count of what we have so far so we can add more info.
  • Make the tweet more 'human brain parse-able'

I first trimmed the day descriptions to gain some more characters.

Sun18:light rain precip%day:13 precip%eve:29 Mon19:light rain precip%day:53 precip%eve:64

I then determined correct spelling was optional and substituted lite for light (lite seemed a better solution than lght or lt)

Sun18:lite rain precip%day:13 precip%eve:29 Mon19:lite rain precip%day:53 precip%eve:64

These helped on the character count, but you could easily argue that these make the tweet slightly less readable.  What we really need is something that shortens the character count and at the same time increases its readability.  For this I turned to Unicode.  If I could find a single character to replace a word like 'Sunny' or 'Rain', I could regain many characters to use elsewhere in the Tweet.  I did find some 'weather' glyphs in a miscellaneous section of Unicode, unfortunately most seem to render into illegible blobs because of the typical small size you see them at. I did find

  • sun:☼
  • snow:✽

but nothing good for rain that was legible at small sizes (does this look like rain on an umbrella?  ). 

So I started scanning the Unicode field for something that 'looked' like rain and settled on ⑊. So using ⑊ for rain, we are at:

Sun18:lite ⑊ precip%day:13 precip%eve:29 Mon19:lite ⑊ precip%day:53 precip%eve:64

I then did a major refactor to the order of things and dropped some 'not completely necessary' terms:

Sun18:lite ⑊ 13%day 29%eve Mon19:lite ⑊ 53%day 64%eve

At this point, a great deal of ground has been made on character count, down to 53 characters, or about a 45% reduction. As a final step, I rely on alpha/digit/symbol boundaries and remove space between them.  In an effort to emphasize boundaries, it is back to Unicode with  → and ▮. So here it is at 49 chars:

Sun18 lite⑊13%day→29%eveMon19 lite⑊53%day→64%eve

Original at 95

Sun_18th:light rain precip%day:13 precip%eve:29 Mon_19th:light rain precip%day:53 precip%eve:64

Now What

The goal now it to allow this logic to all weather tweets with will involve building a NOAA weather speak to Tweet Weather speak translator.  So the overall architecture will be

  • nightly, hit the NOAA API and and parse/cache the forecast on the local server
  • once a day (or more), use that cached data to tweet the forcast

So I'm off to finish that,  the starting point is here on github.  I'll document and cleanup that code as I go along Also looking for feedback on the compaction techniques I'm using for the Tweets, so please comment if you have suggestions

Tagged API PHP