iOS 8 on an iPhone 5: Update Impressions

September 20th, 2014
Comments Off

It’s been several days, but I use my phone pretty heavily, so there are some initial impressions I can share at this time.

Obviously the new Extensions APIs (notification center widgets, share sheets, and of course keyboards) bring some handy improvements. My favorites include the new share sheets for Evernote, OmniFocus 2, and Instapaper.

Evernote’s Notification Center widget, with it’s quick-create buttons, has already gotten some use (I photograph every credit card transaction receipt at restaurants), but the rest don’t seem that interesting. At least not in their present incarnations — it’s definitely early days yet.

But some of the upgrade’s more subtle new features are delighting me. For example, Mail now allows you to indicate that you’d like notifications whenever replies are received in for a particular email thread. I’ve got a bit of beef to address with Handy about some recent scheduling mishaps, and I want to keep on top of it in a timely manner. Unfortunately, I have my work email account on the phone, as well, which is a bit of a firehose — even over the weekend. But since I enabled notifications for that thread, the phone will make sure I know immediately when one of their support reps reply.

Speed-wise, the phone still feels more sluggish that it was with iOS 7 (OS upgrades, however, generally tend to slow down older hardware; even with free OSs, like Ubuntu) but the phone seems to have sped up a little bit as compared to the first day (likely thanks to some caches that actual usage warmed up).

Battery time doesn’t seem to have changed for my usage, though. To be forthright, however, I’m definitely not using any active measurement techniques to compare. That said, these more methodical test results seem to support my experiences.

Definitely pleased with the update, and makes waiting for December for my subsidized iPhone 6 upgrade much easier to swallow.

One minor (though particularly mysterious) glitch, however: I keep accidentally enabling Voice Over, even when I’m only interacting with the Power button. I’m not really sure what that’s about. I’d like to hear if anyone has also run into this.

Frictionless Evernote and the Inbox Notebook

December 26th, 2012

Most folks that know me have, at one time or another, been subjected to my adulation for a pretty fantastic service, called Evernote. For those unfamiliar with Evernote, it’s basically a badass digital scrapbook in “the cloud”. And while there’s loads to be said about what it is and how it can be used, that’s not what this post is about. I’m assuming here that you’re already sold on (or perhaps even merely exploring) how this service can add facilitate your information management.

And so I’d like to share a little storage workflow tip I’ve been using to keep the organization of the information I store into it a manageable affair:

In short, I have a notebook which I’ve called .Inbox and set it to my default notebook.1 I toss whatever content I’ve decided to keep in Evernote there, and worry about making the notebooks and tags decisions “later”.

This default notebook basically functions just like a GTD “Inbox”.

I’ll review the .Inbox notebook periodically to tag everything properly and shuffle it off into the appropriate notebook (or perhaps delete it, if it was meant to be temporary). In my case, this review happens about every couple of weeks, but you may instead find it a better fit to do so monthly or daily, depending on your own preferences and needs.

Granted, choosing a notebook and tags for each note typically takes only 10 – 20 seconds, so you may be wondering: why even bother deferring it?

Sometimes I’ve simply got a reading / discovery momentum that I don’t wish to interrupt. I also capture printed receipts, which happens on my way out of restaurants or stores. I also snap photos of the labels of particularly good amaros when I’m out with friends, and don’t want to spent time fidgeting with notebooks or tags then and there.

Ultimately, using this Inbox lets me save my note without interruption and move on, resulting in more actual notes being taken.

Footnotes

  1. Using a leading `.` makes the notebook appear as the first notebook when Evernote lists them alphabetically.

Cafe Frizzante

April 27th, 2012

It’s high time for my blog’s first recipe. It’s a simple one, to make fizzy espresso. Before you start, you’ll need:

Once you’ve got the necessary supplies on hand, here’s your workflow:

  1. Fill Soda Stream bottle with room temperature water (to the “fill line”).
  2. Attach bottle to the Soda Stream soda maker
  3. Press the “fizzer” button until the machine buzzes, then let go
  4. Press the button again until it buzzes once more, then let go
  5. “Burp” the bottle by unscrewing it until it releases its inbuilt pressure (you’ll hear a satisfying hiss), but do not remove the bottle
  6. Screw the bottle back onto the the Soda Maker to create your seal again
  7. Press the “fizzer” button once more, once again until it makes a buzzing sound, then release
  8. Remove the bottle from the Soda Maker and cap it. Do not refrigerate; leave at room temperature.
  9. Make your coffee (I recommend a double espresso).
  10. For each 1.5 oz of liquid in your coffee, add a tablespoon of the over-fizzed water you made earlier.1

And that’s about it. Just remember, though, that if you add more hot water (for an Americano) or milk (for a latte, cappuccino, etc), you’ll need to add some more of that fizzy water – one tablespoon per 1.5 ounces of pre-fizzed drink.

Enjoy.

Footnotes

  1. A double espresso is a 1.2 to 2 ounce espresso made from 12 to 20 grams of coffee

Responsive Breakpoints and Goldilocks

April 21st, 2012

The practice of defining “breakpoints” (of screen sizes) is a commonly-used mechanism the Responsive Design world as a mechanism for determining what sort of styling rules, experience enhancements, and even types of assets ought to be delivered to users viewing site content with their particular device.

I’ve typically seen these breakpoints chosen with iOS devices in mind: 320px and up for handheld, 786px and up for tablets, and then 1280px and up for laptops and desktops.

But there are loads of devices being shipped by a variety of manufacturers, whose phones are larger, and whose tablets are smaller. And let’s not overlook the possibility that the number of devices will only continue to grow into the future, even if all you might claim to care about is Apple’s iOS mobile devices (which, IMO, isn’t any smarter than slapping a “Best Viewed in Netscape 4″ badge on your website).

So, how better to think of these breakpoints?

One might suggest that a “theoretically pure” approach would be do consider the physical size of the display and to offer up a design and assets that would be experienced well, given that space.

The trouble is that devices have different pixel densities. And before we get all excited about the fact that CSS also supports real-world sizing units, like inches and millimeters, I regret to have to report that these aren’t reliable, either. Even iOS devices, whose screen sizes are extraordinarily well-defined, render real-world measurement units at 3/4 size of the desired sizing (i.e., a 2-inch wide <div> rendered on an iPad measures 1.5 inches with a ruler).

In case you want to check this claim out for yourself:

Inches

3″ x 1″

Centimeters

8cm x 2cm

Milimeters

80mm x 20mm

Purity, as you can see, is rarely practical.

Still, the general goal of matching up layout styling rules appropriately for a given display size is a sound one. And so I’m thinking a more pragmatic approach with similar goals is in order.

Devices and Their Imperfect Pixels

For better or worse, the digital design world uses pixels as the de facto measurement unit. Now, anyone with a lick of experience with digital design (whether it’s creation, implementation, or troubleshooting) will immediately realize that there’s loads of pixel size variety between devices. Very roughly, PC screens have an average pixel resolution of 100ppi, while mobile devices have a resolution of about 160ppi. 1

This is in no small part thanks to the fact that the original iPhone was a 160ppi device, and to Google’s “device independent pixel” work (also called “dp” or “dip”), which notes:

The density-independent pixel is equivalent to one physical pixel on a 160 dpi screen, which is the baseline density assumed by the system for a “medium” density screen.

So, given this loose “pixel-standard” sizing practice, I hunted around for some reference that outlined the screen sizes of some common mobile devices, and found this handy already-year-old matrix from UX Booth, reproduced here for convenience:

Resolution Devices
320×240
  • Blackberry Devices: Curve 8530, Pearl Flip
  • Android Devices: Motorola Charm, Sony Ericsson Xperia X10 Mini, others
  • Symbian OS Devices: Nokia E63, others
320×480
  • Apple OS Devices: iPhone, iPod
  • Android devices: HTC Dream, HTC Hero, Droid Pro, i7500 Galaxy, Samsung Moment, others…
480×360 Blackberry Devices: Torch, Storm, Bold
360×640 Symbian OS Devices: Nokia N8, Nokia C6-01, others
480×800
  • Android Devices: Liquid A1, HTC Desire, Nexus One, i9000 Galaxy S, others
  • Maemo (Linux) Devices: Nokia 900, others
  • Windows Mobile 6 Devices: Sharp S01SH
  • Windows 7 Phone Devices Venue Pro, Samsung Omnia 7, HTC 7 Pro, others
768×1024 iPad
640×960 iPhone 4
1280×800
  • Android Devices: Motorola Xoom, Samsung Galaxy Tab 10.1
  • Windows OS Devices: Asus Eee Pad EP121
  • Apple OS Devices: Axiotron Modbook

Please note that this is a very limited list, and is by no means complete. What is important to take from this data is that a wide range of screen resolutions are out there, and new devices are introduced constantly.

Starting with this survey of device screen sizes, let’s loop back to the idea of using layout capabilities afforded by the display area as the central concern in identifying our breakpoints: which display width offers “enough room” for a image floats, and which for multiple columns of content?2

Next, let’s keep the number of breakpoints practical, for each one introduces some amount of development and maintenance overhead. We’ll need to balance “enough to be useful” vs. “too many to manage”.

Here are my recommendations:

(unknown)
Presume “handheld” / feature phone. Single column. No floats. Serve images at their smallest dimensions (up to 64px wide, usually best served at around 40px-ish).

300px
Handheld-ish device. Single column. No image floats in primary content. Serve images at a “medium” dimension (300-400 px wide), allowing users to “pinch” to zoom in, etc. Tile ads OK.

720px
Tablet-ish screen size. Honor image floats in primary content. Larger images. Still presenting primary content in a single column (i.e., not hoisting sidebar alongside primary content, but potentially giving the sidebar section two columns?). Banner and Tile ads OK.

960px
Desktop-ish screen size. Full-sized images. Hoist sidebar alongside primary content. Any ad size.

1280px
Desktop “plus”. Consider adding supplemental stuff off to the right, like how Facebook automatically adds user chat to the right for wider screens… might be real-time social activity.

Last Thoughts

It’s worth mentioning that the above breakpoints were defined considering layout capabilities, and do not apply to other facets of potential experience “enhancement” considerations, like whether a sequence of images is best presented as a list or a horizontal carousel, which is much more a consideration left to device capabilities such as JavaScript and/or support for swipe gestures.

And don’t forget the idea of 2x image assets for high-pixel density devices (like the new iPad, with its Retina Displayâ„¢), which starts to open the bandwidth measurement can of worms.

What do you folks think of these breakpoints?

Materials

Here are some related materials that inspired this exploration:

And some tools I had in mind:

Footnotes

  1. There are _lots of caveats_ here, but in the world of web design, there’s enough truth in that to serve as a workable fundamental understanding.
  2. Because we’re exploring web design, let’s identify the primary dimension for our breakpoints consideration to be width, since “height” is often best considered “infinite” on web pages.

New iPad Totally Awesome, but Two LTE Gotchas

March 25th, 2012

Like much of the rest of the folks who bought one, I’m really loving the New iPad (aka “iPad 3″). Yes, it really is that wonderful: instantly responsive and fluid, wonderful screen, and even without Siri, its dictation feature is a real boon when I’m writing small bits of text (for me, that’s when I’m marking up PDFs or design comps with feedback for work).

When I got the first one, in 2010, I wasn’t sure what sort of mileage I’d give it. While I was excited to get my hands on one, I didn’t really know how much I’d wind up using it after the “honey moon” was over, and it was no longer that shiny new thing. So I decided to exercise some fiscal restraint and pick just one of the available options for “upgrade” from the base model, between the storage bump (32G instead of 16G), or the mobile data option. Since I had already been happily using my iPhone heavily for on-the-go data access, I decided the extra storage space would give my buck the biggest bang.

Turns out I used the shit out that iPad over the two years that followed, but definitely come to missing the data connection option that I had eschewed on several occasions.

I skipped on the iPad 2, in part for fiscal discipline, but also because I had used the iPhone 4 and knew a Retina Display would be the irresistible iPad upgrade lure. Thank goodness that the 2012 iPad had delivered on that display, too, because the newer versions of all my apps had already started putting a noticeable strain on the CPU and RAM on my two-years-old iPad.

I put my order in for this iPad the day it was announced.

This time, I knew I’d use this thing heavily for the next few years, so I opted to max out the storage at 64G, and — being sick of AT&T’s shitty signal coverage on my iPhone — I opted for the model that supported Verizon’s LTE mobile data option.

Everything about this new iPad is brilliant, and I’m really enjoying having on-the-go data.

I won’t belabor the points about the smooth performance and the dazzling screen you’ll already have learned from other sources. They are indeed that good.

If you’re wondering whether I recommend you get one, the answer is almost certainly “yes”. If you’re similarly struggling, as I had previously been, between the getting additional storage or mobile data, I’m going to say most people would be better served by the mobile data option.

I do have two points of mild warning, however, both regarding the mobile data option:

  1. My high hopes for Verizon’s data coverage have been tempered by actual usage. Neither my iPhone’s AT&T 3G connection, nor my iPad’s Verizon LTE coverage gives me a lick of actually-usable mobile data throughput in my Time Square office. Both devices show many bars of “signal strength”, but trying to actually load content over the mobile data network gets me nothing but quality time with “Loading” spinners. While one can simply write off Time Square as a dead zone for data (as well as the prospect of finding any good food, or much else of particular value, frankly), I’ve also had data timeouts in other places in NYC’s boroughs. Perhaps I’d set my hopes too high, or maybe Verizon just had a surge in the load of new iPad-owner LTE traffic that they’ll adjust to over time. Time will tell.

  2. When data throughput is available on the Verizon LTE connection, it is very (very) fast. When coverage is available, my iPad’s Verizon LTE service is faster, in many cases, than the WiFi connection at my house which has a Verizon DSL Internet connection. So here’s the “warning” part of this point: be very wary of streaming any video content. Most video delivery services are designed to deliver lower-quality video to lower-bandwidth connections, and higher-quality video to higher-bandwidth ones. The trouble here is that the LTE connections are so fast that video streaming services deliver the highest bit-rate renditions of videos to your iPad. This will tear through the allotted data quota of whatever data package you’ve subscribed to far faster than you’d expect.

In any case, I’m delighted to be able to pull the latest posts from my RSS subscriptions into Mr. Reader while waiting for my coffee and eggs at brunch, or to review the tasks I’ve got in OmniFocus and ensure I’m working the latest sync of my data.