Thursday, June 25, 2015

economics, culture, and electronic communication preference

Voice Memo'ing is insanely popular in Buenos Aires right now. It's the confluence of several factors, including economic: in many Latin American countries they still charge you for each SMS, but WhatsApp voice memos is effectively unlimited with a data plan. (I remember when my AT+T plan had an infuriatingly low # of texts per month, given what I knew about what it was costing them.) Over time, the choice of communication format becomes a cultural norm and develops its own accepted patterns of behavior.

My first thought was that it looked too much like a flurry of little voice mails (which I kind of hate), but I realize the UI presentation is very different because each conversation is collated, it's not the big "voicemail inbox" I try to ignore as much as possible on my phone.

The article lists several advantages to the form:

  • it's expressive, and voice carries nuance and feeling that might be lost in text (or made up with emoticons ;-)
  • there's a facility to send the same voice memo to a group of people
  • they're easy to generate while walking or driving
  • they carry their own validation of who is speaking, though this might be a downside in terms of plausible deniability for some...
It reminded me of the Filipino Texting Phenomenon - observed as far back as 2001, it was partially the result of a deal where calls cost money but texts were unlimited. (Again, this probably was in line with the actual cost to the telecommunications company.) A decade later it put the islands ahead of much of the rest of the world for electronic payment in the real world.

I suppose of the culture I swim in made the switch I would follow, though I'd have to learn to be more concise in my speech on the spot, as well as tolerant of other people's pace. (By nature I like to skim and jump back to things, which is not as trivial with audio as with written text.)

Sunday, June 21, 2015

emoticons and emotional fidelity

I'm in favor of emoticons (or smilies, as we used to call them) -- IMs and Texts (and to a lesser extent email) form a blended form of communication, mixing the format of traditional writing with the more casual aspects of spoken speech. Emoticons are ways of pasting over the lack of tone and inflection that the latter enjoys.

(I've noticed some people just sound harsher in email and text. I'm not sure if it's a lack of exclamation points or what- in the case of my Aunt, for example, her friendly intent was more clearly expressed to me when she started using emoji signoffs at the end of her texts)

I like emoji well enough, but I've never been a fan of chat interfaces that used cartoon equivalent for typed smilies, especially when the UI automagically swaps out a :-/ or :) with the yellow-faced "equivalent". I think AOL-IM started doing this in the 90s. I could never figure out if it felt more like a UI engineer showing off or if someone was really afraid people might not get the typographical pun involved. (Perhaps it was just a way of cutting the Gordian Knot around whether the canonical smilie had a dash nose, :) vs :-)  (Not to mention the issue of whether the smile count as the closing parenthesis for a parenthetical aside!)

There's been a lot of interface inconsistency over the years, like whether it was the sender or receiver that was "supposed" to do the conversion-- with extra points off for programmers when a code sample gets ); or :D "helpfully" converted.

And last week I discovered that Facebook adds an extra terrible wrinkle, with a bad inconsistency in the web and iOS form of its chat client. Here is what a :-P looks like on the web:
and here is its appearance in the iOS client:
That's a very different mood, even if the expression is technically the same. (The web version is closer to what I was aiming for, and the set of the mouth closer to what I feel a :-P conveys.)

I feel Apple iMessage gets it about right, leaving typed smilies well alone, but providing an easy interface for adding in a range of smilies (including ones that would lack a typed shortcut equivalent, like rolling eyes) and other fun, goofy little cartoons.

Semi-relevant International Fun Fact: according to my 2007-era self:

it seems common for Russians to forgo the eyes on smilies but multiply the smiles, and just do something like )))) 
Semi-relevant International Anecdote: (this being my my 2003 self)
I learned two new things playing Pictionary with Germans. One thing is that for them, Aladdin's lamp is more of a vase looking thing. The other thing, though, is really big, and might also be a Europe/USA thing, not just English vs German...the Germans have no word for the opposite of smile. And maybe neither do the British. If you look up "Frown" in the Oxford English Dictionary, it talks about wrinkling the forehead, and doesn't mention the mouth at all! They would never come up with a phrase like "turn that frown upside-down", it just wouldn't make sense. I'd love to hear from any British or European folk who can confirm this; it has kind of big implications for the iconography of the different cultures. (Like in Pictionary, the Germans will spend a lot of time drawing wrinkled foreheads...)
Of course, there's a lof differences in how different culture do Emoticons - like the Japanese who orient stuff vertically, ala (^_^) - and of course got into expanded alphabets, allowing seriously fun stuff like ¯\_(ツ)_/¯

Thursday, June 11, 2015

what is code?

Paul Ford on a whirlwind from start to finish What Is Code

Had some nice bon mots:
"Code is inert. How do you make it ert? You run software that transforms it into machine language."
Some parts hit home:
Programmers carve out a sliver of cognitive territory for themselves and go to conferences, and yet they know their position is vulnerable. They get defensive when they hear someone suggest that Python is better than Ruby, because [insert 500-comment message thread here]. Is the next great wave swelling somewhere, and will it wash away Java when it comes? Will Go conquer Python? Do I need to learn JavaScript to remain profitable? Programmers are often angry because they’re often scared. We are, most of us, stumbling around with only a few candles to guide the way. We can’t always see the whole system, so we need to puzzle it out, bit by bit, in the dark.
I was interested on his view on frameworks, he kind of argues both sides, con-:
So what’s the downside? Well, frameworks lock you into a way of thinking. You can look at a website and, with a trained eye, go, “Oh, that’s a Ruby on Rails site.”
[...]
Frameworks have an obvious influence on the kind of work developers can do. Some people feel that frameworks make things too easy and that they become a crutch. It’s pretty easy to code yourself into a hole, to find yourself trying to force the framework to do something it doesn’t want to.
but then pro:
Frameworks can feel a little insulting, because they anticipate your problems and are used by thousands of people. They imply that yours are common, everyday problems, rather than special, amazing mysteries that require a true genius to solve.
Good stuff. 

Friday, June 5, 2015

easy-peasy html 2 pdf

PDF can be an annoyance at times, but it's usually not terrible. It's convenient because it is widely viewable and can embed images and styles and what not. If you're distributing information via email, those factors can make it a win.

Pdfcrowd is an easy way to make a PDF from an html file - it seems to be pretty darn robust in the HTML it handles, from my 15-year-old HTML of my blog to a scheduling table that used a ton of absolute positioning for elements.

The site can be used as simply as entering a URL, but the page I wanted was password protected. So I "Save Page As"d in chrome, then made a new folder containing the html document and its supporting files, zip'd that, uploaded at pdfcrowd and got something like this:
(or rather, that's a screenshot of a PDF reader looking at a parallel process for my public site.)

The free version adds the watermark/site name at the bottom and doesn't have many formatting options, but for quick and dirty it can't be beat.

In the comments Jeremy pointed out that the standard OSX Print dialog has a "Save as PDF" option which is even more convenient, but makes a printer-friendly ink saving version, where colored backgrounds get replaced with outlines. Good to have both techniques in mind!

useful functions in js

7 Essential JavaScript Functions. I really like how this one shows you the code, rather than just bundling it in some kind of library. Transparency is such a good thing.

Tuesday, May 26, 2015

google maps part 2

Last year I wrote about how integrating with Google Maps was pretty easy.

This year I've been helping a few other porchfests, in particular with getting drafts of their map together. (Though fair warning, double check the licensing of Google Maps API)

A bit ago when I was talking about PHP making easy things easy it was using PHP's file_get_contents() to hit the Google Maps geocoding API (URLs of the form https://maps.googleapis.com/­maps/­api/­geocode/­json?­address=SOME+­ENOCODED+­ADDRESS&­amp;­key=­YOUR_­API_­KEY) to convert addresse to the latitude/longitude the rest of the API uses. Wrapping that in a hacky PHP script rather than doing it by hand via a website sped things up, though you have to learn how to see if you've gotten a proper full match, or if it can't find it and is just locating the city center.

So, the site was looking for a printable version of their neighborhood map, with icons for the porches marked, vs an interactive thing for their site. A few tricks and traps:

I used this one Google chart marker API for the pins, though I guess technically that's deprecated - still it was somewhat easier than rolling my own markers in Processing. A sample URL for that was http://chart.apis.google.com/chart?chst=d_map_pin_letter&chld=K|00FFFF|000000 to make something like



Another issue I had was Google was showing me local business names, and that was making the map too confusing. stackoverflow to the rescue, the trick was to hide those via a styler.

Also, previously I mentioned phantom.js as a screencapture tool - in this case it let me make a virtual screen that was bigger than my physical monitor, by fiddling with the viewport size. (Admittedly, this whole thing is kind of weird for print, because you end up with something sized for screen resolutions and not print DPIs)

Finally, I also researched making phantom.js wait for a page to load - or rather, waiting 5 seconds before taking the screen shot, to allow the Google page to settle, when I was zoomed in a bit more. My final phantom.js script was:

var page = require('webpage').create();
page.viewportSize = {
  width: 1800,
  height: 3600
};
page.open('http://localhost/plum2015/view.php', function () {
    setTimeout(function(){
        page.render('plum17.png');
        phantom.exit();
    },5000);
});

Then I had to crop it... rather than setting up pixel magic, it was easier to do it on the OSX program Acorn, which had a nice "set a cropping box at a specific ratio" feature.

Thursday, May 21, 2015

changing the whole URL without the page flash

My coworker pointed out that when you're navigating through Youtube, you can go from page to page and the URL completely changes (i.e. it's not just changing stuff after the # anchor) but parts of the page, such as the side bar, remain constant (tampering with it with Inspect Element proves that it's the same DOM elements, not new copies each time)

I guess that's a thing, now! With appropriate js shims for older browsers. I don't have a reason to implement a proof of concept for myself right now, but it's a good thing to know about.