October 8, 2015 at 9:19 AM by Dr. Drang
If you’re using Tweetbot 4 and have the font set to San Francisco, you may have noticed that text in the Compose screen sometimes reformats itself in ways that don’t make sense. Before last night, I thought I was imagining this, but it happened so often as I was tweeting during the Cubs wildcard win over the Pirates1 I knew it was real.
We’re all used to certain types of reformatting as we type. When we get near the end of a line and start typing a long word, that word will jump to the next line when it gets long enough to hit the right edge of the text field and force a word wrap. What I’m talking about in Tweetbot is seeing words jump back and forth from line to line as I add text after them. Let me show you a couple of examples.
Here’s me typing a reply to noted Yankee fan John Gruber:
The last word, the, starts out on the third line of the reply, but when I type the C it suddenly jumps back to the second line. Later on, a similar thing happened:
When I typed the s onto the end of Cardinals, the the jumped back down to the third line again.
This all seemed very weird to me, so I asked (on Twitter, of course) if anyone knew why. Paul Haddad of Tapbots—a pretty authoritative source, I’d say—answered:
@drdrang the counter is using San Francisco and it defaults to proportional numbers.
— Paul Haddad (@tapbot_paul) Oct 7 2015 10:29 PM
The right margin of the composition field is defined by the width of the countdown field in the upper right corner. When the counter gets narrower, so does the margin, and more text can fit on every line of the tweet. But in both of my examples, the count is two digits long, which suggests an unchanging width.
That’s the point of Paul’s tweet. While most fonts—even fonts that are otherwise proportional—use monospaced characters for the numerals, San Francisco is different. It has both monospaced and proportional numerals and it’s the proportional ones that happen to be used by default. So the margin width changes a little bit every time the countdown value changes, and that’s what’s causing the text to jump around.
It probably doesn’t help that I use a relatively large font in Tweetbot. That magnifies the small differences in the widths of the numerals and means only a few words can fit on every line of the composition field. These two things will tend to cause more text jumps than if I were using a smaller font. But I need to see what I’m typing, so reducing the font size isn’t in the cards.
According to Paul, the next revision to Tweetbot will use monospaced numerals in the countdown, which will eliminate the jumpiness except when the number of digits changes. This’ll be much better, although personally I’d prefer either a right margin with a fixed width large enough to accommodate a three-digit count or to have the counter moved from the right margin to the otherwise unused space under the user’s avatar.
As tweets about this situation went back and forth between me, Paul, and the Egg McMuffinless Casey Liss, I got a tweet from Ian Bjorhovde directing me to this portion of the WWDC session on San Francisco, which talks about how to use the proportional and monospaced numerals.2 It’s an interesting subtopic and lasts only about three minutes. Well worth your time.
David Loehr mentioned that he uses Avenir, the other font that Tweetbot allows. It doesn’t have the proportional numeral problem, but I find it a little too thin and “gray” for comfortable reading. I’ll stick with San Francisco and hope the Tweetbot revision makes it through Apple’s approval process quickly. The revision is also going to fix the chart labeling bug I talked about a few days ago.
I mention this as a way of preserving a record of this rare Cub playoff appearance and victory for future skeptical generations. ↩
I always pay attention when Ian tweets at me. He’s a bright guy in his own right, and he’s also the son of a pretty famous structural engineer whose publications I’ve used countless times. ↩
October 7, 2015 at 10:42 AM by Dr. Drang
Occasionally, I write a post about making charts. Sometimes these posts are rants about poor practice or my thoughts on good practice, but usually they’re more descriptive than prescriptive. I write about how I make charts with the expectation that my beliefs and tastes will come through and that I might have some small influence in stemming the tide of bad charts.
A layout that might work with a few candidates is a mess with fifteen. The legend overwhelms the chart, and there’s no rhyme or reason to the order of the names. The colors are too close to one another. The markers, which could be used to distinguish the candidates, are the same for each.1 The labels for the horizontal axis are stupidly formatted over two lines. Worst of all, the polls are equally spaced horizontally even though the times between them vary from 5 to 14 days.
You might say this is nitpicking and that the important thing is that the chart communicates who’s winning and who’s moving up or down in the polls. You could also argue that there’s no reason to wrote an article with correct tenses or to gets the verbs to agree with the subjects. Them things isn’t important to communication, is they?2
Into this mess steps Kieran Healy, associate professor of sociology at a basketball university down in North Carolina (no, the other one). Kieran is perhaps best known on the internet for a data visualization post that has, unfortunately, become something of an evergreen. His charts are always tasteful and informative because he’s a smart guy and he’s thought a lot about how to communicate through plots.
This semester—half-semester, actually—Kieran’s going to impart his wisdom to grad students in his department through a special topics course. He’s starting out right, by demonstrating the evils of Excel’s overly cute 3D column charts:
A handful of Duke sociology students won’t fix the world’s data visualization problems, but Kieran is making his class notes available on GitHub, so there’s hope that others will find them and learn.
Distinguishing the data series is somewhat easier in the actual chart (as opposed to this screenshot) because you can click or tap the names in the legend and see the corresponding series light up. Of course, you have to know or guess that this is possible, otherwise you’d never try it. ↩
Given my penchant for leaving typos and editing artifacts in my posts, this is a very dangerous paragraph. ↩
October 4, 2015 at 9:44 PM by Dr. Drang
This post from last week by Kirk McElhearn and this followup today by Michael Tsai reminded me that Safari 9 has a new feature in the menu: Responsive Design Mode. Unfortunately, it’s not as smart as I’d hoped it would be. Or maybe I’m not.
The idea behind RDM is to let web designers see what a site looks like on smaller (Apple) screens without continually resizing windows or reloading pages on other devices. You can see how it looks by just clicking a button associated with the device of interest. And, unlike pinned sites, this feature is available on Safari 9 even if you’re still running Yosemite.
I’m not a web designer, but I am responsible for this site, and I do occasionally fiddle with its layout. I (finally!) made a mobile layout back in June, and it would have been much easier if I’d been able to see the results of my CSS changes immediately on my Mac as I made them.
But I soon found that RDM doesn’t really emulate smaller devices. Here’s what my site looks like on my iPhone 5s:
And here’s what it looks like in Safari RDM:
Not exactly a faithful representation. And it’s no better in landscape.
I assume this is at least partially because I don’t really know what I’m doing. I have two CSS files for the site: the original
style.css that’s meant for wider screens and
mobile.css that’s meant for narrower screens. The file used is controlled by these three lines in the
<link rel="stylesheet" type="text/css" media="all and (max-device-width:480px) and (orientation:portrait)" href="resources/mobile.css" /> <link rel="stylesheet" type="text/css" media="all and (max-device-width:480px) and (orientation:landscape)" href="resources/style.css" /> <link rel="stylesheet" type="text/css" media="all and (min-device-width:480px)" href="resources/style.css" />
So I’m really choosing the style file on the basis of the device’s width, not the view’s width. This is a simple solution, and it works, even though it isn’t fully responsive. If you’re reading this on a phone and rotate it, the layout will change; but if you’re reading this on a notebook or desktop computer and make the browser window narrow, the layout won’t change.
I don’t really want to mess with the site’s layout again, and I certainly wouldn’t do so just to get it to work in Safari’s RDM, but there are two things that’ll probably force me into it: iOS 9’s Slide Over and Split View on iPads. I’m pretty sure those views don’t change the
device-width, and if I want the site to display its narrow layout when it’s in those modes, I’ll have to make it truly responsive.
Eventually. I’m not particularly responsive, either.
October 3, 2015 at 8:44 AM by Dr. Drang
I’ve been using Tweetbot 4 for a few hours now, and I really like it.
This is not a review. There are several other places you can go for that. What I want to talk about are the little charts it provides in the Stats view. They’re fun without being obsessive the way Twitter’s own analytics charts are.
At the top is an activity timeline for the past seven days. By going back only seven days, the chart is clean, uncluttered, and easy to read at a glance.
You’ll notice that it’s a Bezoan chart, with no scale for the vertical axis. I think that’s OK in this context. The idea is to give you a quick sense of what’s been going on for the past week. Again, if you want to pore over the details, go to Twitter’s analytics site to see how many of your followers are self-employed weight conscious Verizon users.
One thing about this chart that I’m pretty sure is a bug is the horizontal labeling. Based on how the final point starts low and rises through the day, I believe it represents the current day’s activity, even though it’s labeled as yesterday. In fact, all of the day labels appear to be one day off.
Below this chart is a list of your tweets, each with bar charts showing how often it’s been favorited and retweeted.
The two bars obviously aren’t drawn to the same scale, but what scales are they drawn to? Tweetbot’s Paul Haddad gave the answer in a tweet a couple of days ago:
@chase_mccoy all relative to your most popular tweet of the last week.
— Paul Haddad (@tapbot_paul) Oct 1 2015 6:01 PM
I think that’s a good choice and is in keeping with the seven-day scale of the chart at the top. In this case, the absolute numbers are given, but the bar charts are relative to the past week. If you keep scrolling down, you’ll start seeing tweets that are more than seven days old, and it’s likely you’ll run into some that have more favorites or retweets than the seven-day maximum. Those bars are pegged to the right end and don’t give an accurate representation of their value, but their numbers are still correct. You just have to keep in mind that the charts on this screen are all based on the past week.
Overall, I like these new Tweetbot charts because they’re fun and casual. Social media professionals will probably not find them acceptable, but who cares what they think?