Fixing Missing Sound Output

As I was trying to troubleshoot why my media center Mac Mini froze twice over the last 2 days, I discovered that the sound output didn't list the Built-in speaker. After a bunch of searches with different suggestions, I decided to reset the NVRAM. The problem is that the Apple support docs say to use Command-Option-P-R at startup and my Mac Mini doesn't have a monitor or keyboard hooked up to it. After some additional searching I found the following command:

sudo nvram -c

and then a restart. After I did that, the sound output options were back. Yeah! Does this solve the freezes I've seen? I have no idea, yet, but at least I know one problem is solved.

The best, underutilized and poorly implemented accessibility feature

[Update - October 21, 2015: It looks like the issues with News have been fixed with the iOS 9.1 update. Yeah!]

iOS 7 brought a feature called dynamic type which moves away from developers specifying exact point sizes for text and instead uses a number of descriptions for fonts.

From UIFontDescriptor.h:

    // Font text styles, semantic descriptions of the intended use for a font returned by +[UIFont preferredFontForTextStyle:]
    UIKIT_EXTERN NSString *const UIFontTextStyleTitle1 NS_AVAILABLE_IOS(9_0);
    UIKIT_EXTERN NSString *const UIFontTextStyleTitle2 NS_AVAILABLE_IOS(9_0);
    UIKIT_EXTERN NSString *const UIFontTextStyleTitle3 NS_AVAILABLE_IOS(9_0);
    UIKIT_EXTERN NSString *const UIFontTextStyleHeadline NS_AVAILABLE_IOS(7_0);
    UIKIT_EXTERN NSString *const UIFontTextStyleSubheadline NS_AVAILABLE_IOS(7_0);
    UIKIT_EXTERN NSString *const UIFontTextStyleBody NS_AVAILABLE_IOS(7_0);
    UIKIT_EXTERN NSString *const UIFontTextStyleCallout NS_AVAILABLE_IOS(9_0);
    UIKIT_EXTERN NSString *const UIFontTextStyleFootnote NS_AVAILABLE_IOS(7_0);
    UIKIT_EXTERN NSString *const UIFontTextStyleCaption1 NS_AVAILABLE_IOS(7_0);
    UIKIT_EXTERN NSString *const UIFontTextStyleCaption2 NS_AVAILABLE_IOS(7_0);

When developers use these instead of say Helvetica Neue 12, a user can change the font size in Settings->Display & Brightness->Text Size.

This is generally thought of as an accessibility feature as it helps people who have trouble seeing. However, for people like me who can see well with glasses, larger type is just more comfortable to read. Implementing this is quite easy, but requires a few extra steps like listening for changes to the fonts and making sure that table rows resize to accommodate the text. These steps aren't rocket science and don't take much effort, but many developers are constrained by what their designers give them and many designers are still used to specifying exact fonts as well as spacing. This needs to change as it is hurting those that want to increase the font size and also makes it harder to adapt to different screen sizes.

I've implemented dynamic type in a few of the apps I've done and it worked out well; the extra effort was worth it in my opinion. Some developers just don't care and other developers including Apple make an attempt, but fall short.

Here are images from the Apple News app. The first image is the standard text size; the second is the largest text size (largest before going into Accessibility and moving it to super large).

(I never knew there were images with the posts because they aren't seen with the large text.) You can see that the text resizes along with the cells, but the title collides with the first part of the article. That's pretty sloppy.

The next example is in Calendar. This one is worse than the first because the row is a fixed height and it looks like each row of text is also a fixed height so that when a larger font is used, it looks awful.

For a company that pays so much attention to accessibility, these examples show that individual teams making the apps aren't doing enough to look at their apps. Maybe all the engineers have great eyes and can see the text, but this does need to get fixed. (Filed as Apple Radar 23196322.)

Outside of Apple, developers need to pay more attention to this; accessibility is hard and I'll be the first to admit that I don't do enough on accessibility. Handling dynamic type is an easy first step in making apps more accessible and easier for everyone to use.

Recovering from a hack

At the end of last week, I got a message from my sister about a problem with her email account. It is a Google Apps for your Domain account and luckily, I don't manage it! Around the same time I got her message, I received email from Google that her account was suspended. Turns out when I setup the Google account, I added an admin account for me and had email forwarded to my main email address. This turns out to be a good thing as I was able to reset her password and get her going again. My sister explained that she had checked her email from her work Windows machine and it had some type of virus/malware on it and that caused her account to be compromised. Ouch. Like a good brother, I helped get things going again and told her (and the rest of my family) to enable 2 factor/2 step authentication everywhere it was available. In addition, I told her never to check her Google email from her work computer and just use her phone. That's probably good advice; don't use machines that aren't under your control if you can help it. Email can wait and with a smartphone, it is easy enough to check mail on the phone.

Her email address (not the account) was then used to send a bunch of spam. Unfortunately, there isn't much that can done about it. However, since I have control over the DNS for her domain, I setup SPF and DKIM so that any service that implements either or both of these will mark any mail that doesn't originate from Google servers as spam. Email that originates from a server not identified by SPF will have something like this in the header:

Received-SPF: fail (google.com: domain of person@example does not designate 185.27.28.62 as permitted sender)
client-ip=185.27.28.62; Authentication Results: mx.google.com;