Typography Nerds

One of the things I love about being a typography nerd is that one can spend an inordinate amount of time fiddling with kerning, line-height, or even finding that perfect serif for long form reading. I’ve redesigned this site numerous times over the years, changing the layout in vast ways, as well as experimented with countless sans-serif, and serif fonts.

I’ve been truly happy over past six months with Palatino as the sole font on this site, but I decided the other day to try switching everything to just Baskerville. Baskerville is also a much beloved serif that ships with Mac OS X and iOS, and it also holds a place in my heart. I can’t say with certainty that I prefer it over Palatino, as the differences are more nuanced, and less black and white.

I believe it takes some time before one can come to truly appreciate a font, and this is why I decided today to leave Baskerville on this site for at least a week. I can’t say with certainty I will go back to Palatino, but I’m really starting to like it.

I have already tried adjusting the font size and line-height, as some of the settings I had for Palatino are non-optimal for Baskerville. We’ll see how things go over the course of the next week.

Instant-On MacBooks

One of the features I’ve wanted since the inception of the iPhone and iPad is instant on and off for my MacBook Pro. As solid state storage prices continue to plummet year-after-year, and as Apple continues to fine-tune OS X, we seem to be getting much closer to this being a reality.

The current generation MacBook Air is no slouch. It boots in a matter of seconds, and can go to sleep and wake up extremely quickly. There’s still more work to be done, and instant-on is a feature that needs to be across the board with all MacBook products. If Apple were to remove the optical drives from all MacBook Pros, fill that space with higher capacity battery, and move to the same small package SSD drive that the Air uses, this would be my ideal configuration.

On the subject of battery performance, the iPad has thirty days of standby time on a single charge. At some point we’ll get there as well on the MacBook line, however, there are far larger problems to deal with. First of all, on iOS devices, Apple doesn’t use x86 architecture. Macs are powered by Intel processors, and iOS by Apple’s own A5/A5X. Unless Apple eschewed Intel for Arm architecture on Macs, I can’t see huge strides being made by Intel on the mobile chip from as far as power consumption is concerned. Sure, every year Intel manages a die shrink and squeezes in an optimization here and there to improve power consumption, but they aren’t making improvements at the rate we need.

You can’t ignore the software. It’s unequivocal that developers need to work hard to ensure optimal tuning for battery performance on mobile computers. Release after release, Apple has continued to push forward on making sure each new version of OS X is optimized for the latest generation hardware, thus improving battery performance. This isn’t any different with OS X 10.8. Whilst I have yet to try Mountain Lion, I hear some people reporting that the developer previews — coupled with the latest generation MacBook Air — equate to much faster cold boot and sleep/wake performance. This is welcome news, and I can’t wait to see just how much better Apple can do with the imminent release these new MacBooks and Mountain Lion later this summer.

It Is Only A Matter of Time before Google Exerts More Control over Android

It’s only a matter of time before Google starts to feel that it should exert more pressure on its device manufacturing partners. In fact, this is happening right now (for reasons I’ll get into). I’ll posit that ODM’s (Original Equipment Manufacturers) need Google more than Google needs them (for now).

Presently it may seem preposterous that Google could continue to do well with Android if it didn’t have Samsung, or perhaps HTC to a lesser extent. When Google purchased Motorola mobility last year, they made a clear statement that they had no plans to screw over (obviously I’m not quoting verbatim here) their partners. The reality is Google needs to do something about the fragmentation of the platform. Most people seem to be cognizant of this as well outside of Google — be it third party developers or tech savvy consumers.

We may not see massive change overnight, but it feels as if things will incrementally change from here on out. First it’s an acquisition of a substantial mobile phone company (Motorola), and then it’s Google selling their own devices directly to consumers — sans carrier contract.

Amir Efrati reporting for the WSJ:

Google will work with as many as five manufacturers at a time to create a portfolio of “Nexus” lead devices that include smartphones and tablets, said a person familiar with the matter. Google also plans to sell the gadgets directly to consumers in the U.S., Europe and Asia through its website, and potentially through some retailers, this person said.

This strikes me as the smart and correct thing to do. Sure, this won’t solve the fragmentation issue overnight — quite the contrary, it will never be fully eliminated unless Google takes full control over the manufacturing of the hardware and software.

I’m sure Google in the present day loves their device partners, but this can change quickly. What Samsung has done to propel Android as a platform can’t be ignored. The sheer number of Android devices Samsung sells makes it one of the top mobile phone manufacturers. If I were at Google, I would be devising ways of how the company could slowly start to push third party ODMs out of the way. Envisage what Android could be like if Google fully owned the hardware and software experience, from top to bottom? Indeed some may be thinking right now that this would mean far too much control, and that Android wouldn’t be “open” enough. I posit that a fully owned experience by Google could still retain the more flexible nature of Android that the company initially envisioned and conceived. This could happen, all whilst keeping the operating system a complete and cohesive experience — sans carrier app bloat and third party skins messing around with the pure Android experience. There’s zero reason why having full control over the hardware and software experience means that Google would suddenly make Android less flexible to tinkering.

Another part worth citing from this WSJ piece:

Carriers also are sometimes slow to push through software updates to phones, and they preload apps of their own choosing on devices. By avoiding carriers, Google and its hardware partners can get devices to market faster, often by several months.

They’re sometimes slow to push through software updates? Try always. Carriers couldn’t care less about support existing customers. Instead of pushing out software updates, they would rather you just buy a new phone. This is the sad world many Android customers are facing today. This also isn’t just about Google being able to push out devices to market faster though. The much bigger picture is that Android users will be infinitely more happy with updated devices, rather than getting screwed on after sales support twelve months onward. And Google will no doubt love ensuring that these same people are experiencing Android the way it’s meant to be — to wit, with the latest and most innovative UI and UX to come out of their labs.

Small baby steps are needed to get Google to where they need to be. They know they can’t pull the plug on their partners right now — lest face their pure unadulterated wrath. But perhaps selling their own devices directly to customers, as well as owning Motorola mobility will put them in a position of power one day. Perhaps now it may seem foolhardy of me to think things will change in the not to distant future, however, I’d honestly love to see Android evolve in the right direction as a beautiful alternative to iOS. This is not a matter of Google not having enough talent to pull it off — after all, Ice Cream Sandwich was a massive step in the right direction. The herculean task Google is faced with right now is fully controlling Android’s destiny — something that seems slightly ambiguous to me considering the plethora of different devices with different versions of the operating system available today.

Instacast 2.0 And The Entitlement-Minded Morons

I love Instacast. It’s the best podcasting app that’s available for iOS as far as I’m concerned. I’ve been a fan of it since day one too, and this 2.0 release certainly does not disappoint. Here’s the thing: since Apple has no infrastructure in place to support paid app upgrades, developers are forced to either take massive profit loses by charging very little, or offer in-app purchases in an effort to recoup their some of their development costs. This is what happened with the recent release of Instcast 2.0 for iPhone (the iPad version will get updated later on). The developer, Vemedio in this case decided to drop the price of the app from $4.99 to $0.99 — though some features previously had were removed and added into a “Pro” in-app purchase for $1.99 — arguably this price is a pittance.

I’ve been involved in the software industry for a number of years, and have worked closely with developers, project managers, and designers. I know how hard all of these people work to ship a major new release. Shipping is not easy. You pour your heart and soul into the product, and hope that the pricing is right to sustain further development. Once you ship, the party doesn’t stop. You need to have a healthy dose of cash flowing in every month in order to pay people to continue to iterate and work on your app. If you’re just a one man or woman development shop, you may only need worry about yourself, however it’s even more important that you have a sustainable business model so you can remain self-employed.

It saddens me when I see a small development company like Vemedio release a great 2.0 product, but get rewarded with plenty of one and two star reviews — all people bitching about the pricing structure change. Look, I get that some people are pissed off that features they previously had, such as playlist management, were removed and then added as an in-app purchase. The thing is, $1.99 is such an insignificant price to pay for that plus a few other great features. Unlike what some believe, push notifications were never a feature in Instacast 1.0 (only local notifications were supported). I look at the in-app purchase as a way of funding the continued development of a fantastic product. Besides, if 2.0 were released as a completely separate product, you’d end up paying more for a major upgrade — likely $4.99, which was the original price prior to the latest release.

As soon as I installed 2.0, I happily paid the $1.99 for the in-app purchase. There’s no good reason why anyone should be upset by the new pricing structure of the app. Since the inception of the App Store and the $0.99 impulse buy, we have cultivated an ecosystem where incredibly powerful software is available for purchase for less money than what you spend at Starbucks every month. Unfortunately, some people have a huge sense of entitlement, and think they’re now owed something for nothing when developers decide to offer things like in-app purchases.

We simply can’t continue to foster a robust ecosystem of amazing app development, if developers themselves are constantly pressured into lowering the price of their apps — all whilst delivering more and more features to the end-user. This is beyond a shadow of a doubt, not sustainable, and it’s an unrealistic expectation for any of us to have.

If you enjoy beautiful, hand-crafted software on your iPhone, there’s zero reason why you should hesitate to buy the $1.99 in-app purchase. You won’t regret it, not to mention you’ll know that money is being funnelled back into the continued improvement of a truly great product.

Lest We Forget The Talented Designers And Developers

Everyone benefits from competition — both we the consumers, and technology companies — makers of our products. Competition means not only choice for everyone, but also keeps the makers of the products we use on their toes.

Companies like Apple are one of the rare examples that I can think of that have superlative industrial design and innovation on their own — without being influenced by other competing companies. Whilst I’m primarily an iOS user, I still yearn for solid competition in the mobile space. This is not because I wish Apple ill will, or wish them to be knocked off their proverbial throne, but because they need strong competition. Even the best companies that are filled to the brim with the best talent need solid competition. This is just a healthy way for the entire industry to operate.

Now well into 2012, everyone — including RIM — knows they’re struggling to keep afloat. I’ve discussed this before back in January, and the future outlook for the company doesn’t look promising — in fact I’d go as far to say that it’s down right depressing. That being said, I wanted to acknowledge something that RIM deserves credit for. Whilst the upper echelons of management are arguably bozos, the company has many talented developers and designers working underneath. It is easy for us to forget, or worse, dismiss these individuals. Worst case scenario, the company is sold off, and everyone loses their job. The sad part is the super talented designers, developers, and everyone in-between — except upper management — will lose their jobs without being paid out millions of dollars in severance fees. At big companies like this, the talented people that contributed to a product get virtually nothing, yet the people in charge running the business get millions of dollars for sucking.

Today news broke about BlackBerry 10, and by now you’ve more than likely gone through some of the screenshots that have been released. Judging purely on the screenshots that I’ve seen, there are some elements that I see borrowed from iOS, but there are also some elements borrowed from Android and even Windows Phone 7. I also had a chance to look at a quick video posted by The Verge on how the actual interface and elements interact with each other. I must say it’s not looking bad at all. Dare I say some elements kind of look webOS-ish. That’s only a good thing, as webOS had a lot of great things going for it — things most people will never experience.

I’m looking forward to seeing how BlackBerry 10 turns out when it ships. I’d absolutely love to play with a loaner model if I can get my hands on one. Let’s hope those devices actually ship this year.

Firefox: Not A Good Citizen on OS X Lion (Part 2)

Yesterday, I opined how Firefox on OS X does not behave like a proper Cocoa Mac app. That’s because it truly isn’t, however, I didn’t go into the technical details as to why — though this was for the sole reason that I assumed most readers are technical enough and already were aware of the reasons.

On that note, I received a very thoughtful piece of reader mail this morning, and Justin gave me permission to share his comments.

Justin cites:

To make a long story short, from what I currently gather and understand, Firefox doesn’t hook into the system-level UI toolbox in the Cocoa API the way conventional Mac apps are. As a result, Firefox doesn’t use NSToolbar for its toolbars, and the URL field doesn’t use NSTextbox, the way Safari or Camino do. Firefox instead uses a custom UI layer based off of XUL. This is what allows Firefox to be easily skinnable/themeable, and it’s what allows for Firefox to maintain some level of UI coherency among Windows, OS X and Linux (KDE/Gnome). Opera also takes the same approach, and it’s why in both cases, the developers had to rely on a UI designer to custom create a default OS X theme which approximated the basic Mac UI conventions as closely as possible. This means that Firefox is a poor Mac OS X citizen by design, to accommodate theming and cross-platform compatibility.

That’s why Camino was such a compelling alternative (and continues to be a compelling alternative to me). By essentially embedding Gecko in a Cocoa shell, they created a browser which has the same engine and the same power as Firefox, while at the same time obeying and using all of the Mac’s UI conventions and features (but it also is the reason why Camino never supported theming or plugins, one of the most heavily demanded features made for Camino). Sadly, with the Mozilla developers ending support for Gecko embedding, and with development of Gecko far accelerating past Camino, this is all coming to an end sooner or later.

Justin is spot on, however, I’ll also reference a great piece by Mozilla Gecko engineer, Josh Aas. This is worth a re-link, as it’s a couple years old, however still holds water in 2012 as far as Firefox is concerned.

Josh Aas back in November 2010:

We dropped ATSUI for text rendering and moved to Harfbuzz and Core Text. The move to Harfbuzz for many operations was done for security reasons and in order to expose advanced typographic features. Font handling is difficult in general, and even more so in web browsers. We’d prefer to depend on open source font code if possible because we can patch it quickly and participate in improving it.

And:

We also added support for the Cocoa NPAPI event model and the Core Animation NPAPI drawing model. These specifications are a big step forward for browser plugins on Mac OS X. They are easier to develop for, properly documented, and designed with IPC in mind. As of version 10.1, Adobe’s Flash plugin supports Cocoa NPAPI. Which leads me to the next improvement…

Firefox 4.0 marked a monumental improvement for Mac users. As Josh explains in his piece, many portions of the app that weren’t written with Cocoa APIs, were in fact re-written. That being said, the user interface is still by and large built from Mozilla’s XUL. For various reasons of good cross-platform compatibility and reasonably fast deployment, I can’t see Mozilla forking the Mac version of Firefox and rebuilding the entire interface using only Apple’s tools. This would be a massive undertaking, and I get the feeling that this isn’t something that Mozilla is willing to do at this point. I’m confident that the people working on the OS X version have absolutely good intentions to continue to improve it. One only need look at the Firefox nightly builds to see how much work is going into the UI/UX of the app.

As always, I will continue to try future versions of Firefox. From what I’ve seen in the latest nightly builds, it’s going to get a hell of a lot better real soon.

Firefox: Not A Good Citizen on OS X Lion

I’ve been a long time Safari user. In fact, I continue to use it today as my primary web browser. I’ve never been averse to trying other browsers of course — what good geek wouldn’t try new software? This is something I have and will continue to do.

One browser that I have never been able to use full-time is Firefox. On the Mac, it just never felt quite right — it felt out of place and never well behaved like a native Cocoa app should. For the most part, Firefox has come a long way over the years. Just in the last twelve months, Mozilla has ramped out their development efforts on the browser. They’ve committed to much speedier releases — opting for constant iteration and smaller, more palatable builds — rather than waiting a year or two for the next major thing. Along the way, they’ve obliterated hundreds, if not thousands of bugs, increased performance, fixed massive memory leaks, and even re-written large portions of the app in Cocoa.

So here we are in April 2012 with the new release of Firefox 12. This is certainly not the same browser you knew a year or two ago. It’s faster in every way you can imagine — from web page rendering to interface improvements. There are, however problems with this browser that really annoy me. Problems that haven’t gone away with every release since version 8.0 on OS X Lion.

With the release of OS X 10.7, Apple added full-screen support in many of its own native apps — in addition to an API to allow developers to build this functionality into their own apps. Versions 8.0 through 12.0 have yet to support this functionality.

Another important feature was the addition of iOS-style scroll bars. I personally happen to like the way scroll bars disappear when not in use. I love the clean look and focus of the content on screen. The problem with Firefox here is that they have yet to release a version that supports this.

Lastly, Lion introduced inertial scrolling. That fun and quirky rubber-band effect when you hit the bottom of a list or page view — borrowed completely from iOS. Once again, Firefox still ships without this support. Scrolling is not smooth in the browser — in fact it’s complete shit. To quell this complaint, I find myself having to dig through Firefox’s preferences to turn on smooth scrolling. Why isn’t this on by default Mozilla?

Lion is not a new operating system, so the people at Mozilla have had plenty of time to support some of these innovative features that other third party developers have long embraced. How many more versions of Firefox do we have to go until they build a proper Mac browser?

The Problem with iCloud and Instacast

I don’t blame developers for having a rough time with implementing iCloud syncing into their apps. Between Apples less than stellar iCloud documentation — not to mention issues with the service itself — building iOS apps that rely on the syncing itself is tough. In the end though, users end up suffering from poor experiences (in turn the developers suffer as well when they deal with angry customer emails).

Being on the user end of things, I know all too well how painful it can be to deal with syncing app states between various iOS devices. Just as an example, I use Instacast on both my iPhone and iPad on a daily basis. Many times I’m switching between my iPhone and iPad, depending on what I want to carry around me. It’s crucial that I be able to put down my iPhone in the middle of a podcast, pick up my iPad, and carry on from pretty much the exact point where I last left the episode.

Between switching iOS devices, one thing that seems to work more reliably than anything else is syncing your position in the timeline. I can’t remember the last time it didn’t sync this properly (though it’s not 100% perfect either, and not as fast as I’d like). This is great, as it means I won’t be annoyed that the episode I was listening to isn’t exactly where it needs to be.  Where Instacast seems to go wrong many times is re-downloading old episodes of various podcasts that were already marked as well. Without a doubt, this is indeed annoying. What makes this worse? On both of my iOS devices, I have Instacast set to sync both the episodes as well as the downloaded version as well. I always prefer Instacast to cache my episodes while on Wi-Fi so I don’t have to eat up my monthly allotted data in order to stream. Syncing downloaded episodes is a great feature in theory, however, more times than not I end up with already listened to episodes on more than one device.

The last glaring issue I’ve encountered seems to be with podcast artwork. On numerous occasions, I’ve had Instacast play the correct episode, yet display the wrong piece of artwork for that show (usually artwork belonging to another podcast that I subscribe to). Whilst my day isn’t ruined, nor is this an earth shattering bug, it’s still annoying to have to deal with. I’ve seen at least one other odd scenario where the app will decide to not only display the wrong piece of artwork, but display artwork for a podcast I had already unsubscribed from. To me this says that its caching mechanism is kind of borked. I’m not 100% certain it’s not directly attributed to some quirky iCloud syncing bug, but it’s just a theory.

Once again, I don’t necessarily fully blame the developer, and iCloud syncing has certainly gotten much better as of the latest release. There certainly are big constraints you need to deal with when syncing data to iCloud and to and from various iOS devices. Things to take into account are: network performance, such as how reliable is it to sync data between devices that are on different wireless networks? In my example, I’m not always on Wi-Fi, and my third generation iPad supports the immensely faster LTE wireless network, whilst my iPhone 4S just supports HSPA+. So when you have two different devices on two different wireless networks that vary greatly in speed, I’m not sure what more I can expect from iCloud.

With the release of OS X Mountain Lion on the horizon, I’m hoping that Apple finally beefs up their iCloud developer documentation. This will not only make developers lives less stressful, but it means they can build more robust and reliable apps — all on the solid foundation of Apple’s iCloud syncing services.

Static Images

I decided to try out Wired magazine on the iPad. Since I’m only familiar with their print magazine, I figured their digital version would be as nicely laid out as the print version. Clearly I’m far too naive. 

It seems like they got the pricing just right. At $1.99 per month, or $19.99 for a year, there’s no question that this is very affordable pricing. In fact, this pricing structure undercuts the print magazine at $5.99 per issue. Of course this is as it should be — paying the same or more for a digital only subscription is completely unrealistic today (sadly many publications have yet to figure this out).

After subscribing, I downloaded the gargantuan April issue at 789MB. The good news is it took less than five minutes to download over LTE (there goes my data cap). The bad news is the user experience is absolutely horrible. The size alone is bad enough, however what’s worse than the file size is what follows (I’ll talk about the implications in just a moment):

• Massive static images
• No selectable text
• No ability to share articles

When I first loaded the April edition, I started navigating through various articles. Every single article is simply a massive image, and thus needs to be rendered every time you look at it. There are many problems with this — the first and immediately noticeable being the page looks blurry for a second or two while it renders. The second major issue — this is a massive and glaring one — is there is simply no way to select any text inside an article. This also segues perfectly to the fact that you also can’t share articles via various social networks (or even email). Many times when I share an article I like, if I’m on any of my iOS devices, I like to select a passage of text and quote it, and then copy the link and share it on Twitter. The fact that I can’t do any of this is unacceptable in 2012.

I’ve known for a while that many publications have been releasing their newspapers and magazines as massive PDFs, however I figured this finally would have been sorted out by now.

Man, I was so naive.

Screens VNC

I decided to leave my MacBook Pro at work last night. Figured I could just use Screens VNC if I truly needed to remotely access resources on my Mac from home. Turns out, this works extremely well.

Screens VNC, like any other similar VNC app available in the App Store, does mouse emulation. My primary concern with mouse emulation was how responsive and smooth it would feel when interacting when elements on my Mac. The initial fears I had were quelled once I accessed my Mac for the first time. My initial tests were done over my very fast home Wi-Fi, however, I did briefly test over LTE and got excellent results as well.

The design of the app itself is quite beautiful, however it also manages to provide some excellent setup instructions for novices. There’s also a super handy automatic discovery of local network computers option — whereby it attempts to automatically populate the recommended settings you need to connect to that Mac.

Over the weekend, I did a little demo for my father who was really interested in being able to remotely access Windows servers. He’s been strongly considering replacing his laptop with an iPad, however, he said the deal breaker would be if he couldn’t find a good way to remotely access Windows servers on the iPad. I configured TightVNC on his Windows 7 laptop so we could try out Screens. After only a few minutes of playing around with the app, he was pretty much sold on the idea.

Screens VNC for iOS is a universal binary, so one only need purchase it once to get it on any iOS device. I should also note that Edovia also has a Mac version of Screens, however, I have yet to test this app. That’s something I’ll leave for another day.

Oh, and one more thing, the app supports iCloud for syncing your settings — something every iOS app should support.