Shiney Code

More than 30 days have elapsed since I put myself on the AppCode challenge. So you may ask, what’s past that cliffhanger? Wait for it…

I felt crippled managing the codebase when I was not in AppCode. The lack of proper refactoring functionality and inability to find references in a quick and efficient manner slowed me down a lot.

By the end of the month, the list of things that allowed me to be more productive with AppCode grew so big that I could look over the few minor caveats it had. I am sure those will be improved upon in the upcoming releases.

No tool is perfect but this one got me pretty close for my needs.

I switch back to Xcode when I need to, but 90% of my time is spent with AppCode. So there you have it.

I was talking to @apontious recently about an episode of his podcast, EdgeCases and his thoughts on trying out AppCode aka @jetcidr. He didn’t really like AppCode very much but it provoked me to consider trying it for 30 days to see how I feel about it vs Xcode.

Since the dawn of my Xcode time, which started about 3 years ago, I thought that it was a suitable IDE for development. Suitable - yes; Great - absolutely not. Like many things in life, one learns to live with Xcode’s many quirks such as its inability to easily refactor code or find usages of properties and methods, the far too periodic, lengthy appearance of the beach ball while attempting a trivial task, and best of all, crashes at inopportune times. You learn to say to yourself over and over that as a developer, this is the pain you must endure to build neat things. 

Filing this under a very misleading error message:

The first screen I got the 2nd time I launched this app was this:

When I saw this, my first thought was that I must have left my phone on Airplane mode. A quick glance at the top of my screen told me otherwise so I hit the ‘Retry’ button which gave me the same results once more. Then I realized that I had not allowed this app access to Location Services when I had initially tried it out. 

Improvement from Version 1

A few days later, I noticed that this app had an update so I refreshed it. Here’s the same error, with better information:

What I really liked about this version (besides a better language about the error) is that they tell you how and why they want your location. This is a very nice touch and I applaud their transparency. I wish more apps would be explicit about why they want my location data.

Recently, I needed to buy a very banal item for our home: a programmable electrical outlet timer. I fully acknowledge that this is over-thinking of a simple purchase but I want to share the one overwhelming factor that influenced my action.

I’ve used a number of the digital timers over the years. Every single one of them has their own quirky and convoluted way of doing one simple task - setting the timer to go off at the same time, every day. I can’t think of a more basic and elemental task but on most of them, it would take more than a minute or two to set it, which is far too long in my opinion. Additionally, they all typically accompany by a 20 page manual that for some reason is compulsory reading.

So when faced with two equivalently priced products at the store, what do I do? Buy the simple mechanical timer that’s this one.

Why? Because just by looking at the front of it through the clear packaging, I could easily tell what needed to be done to configure it. 

When I opened up the packaging, I could quickly discern that I either need to push down or pull out the small buttons to set the timer. All I had to consult the manual for was to verify which position was ON or OFF. Where was this information? Clearly shown with a picture on page 1 of a 3 page manual.

Okay so you’re asking, “So, what does a mechanical timer have to do with software?” I purposely didn’t buy a fancy timer because I didn’t feel that I needed to deal with year another quirky interface to operate a simple tool in my house.

The reality is that I think most people in the world don’t feel the same way about gadgets as those of us who try to design and build them. We care that we can tinker and tweak software to our heart’s content, maybe modify it to improve, or just break it to learn from it. The rest of the world, meanwhile, just want to go on about their day with tools that just work. 

What’s the solution? When we start designing a cool new piece of software, be it for a browser, smartphone or a microwave, we must absolutely stop fooling ourselves and believe that everyone else in the world likes to spend their time troubleshooting and “playing” around with gadgets. Instead, we should always run it through 3 tests:

1) Can at least 75% of my non-developer friends use it without having to scratch their heads or even have a momentary feeling that they need to read the manual?

2) Make it pass my Mom test. It’s a cliche used in our industry but she really doesn’t want to read any of the product manuals and usually makes me do it.

3) Would I use this, had I not worked on it?

In the last post, I described feature requests I’d like to see in the New Yorker iPad app. I also hinted at my desire to love the app, but a number of strange quirks with it leave me wanting more.

I should note that one of my favorite apps on the iPad is Flipboard, because I think they’ve done a pretty stellar job in designing a good experience for reading content on the device. All my suggestions would go away if  the New Yorker was published via Flipboard, but that’s probably not going to happen very soon unless the two companies hash out some agreeable subscription terms. Until then, here’s a list of what I’d change in v2.0 of the app.

1. Which Way Do I Flick to Move Between Pages? 

The most awkward feature of the app is the navigation from one page of an article to the next. The New Yorker makes you flick downwards on the screen to move from page 1 to page 2. I can’t tell you how many times I was reading a page and flipped left to right to move to the next one, only to be annoyed that a very natural and intuitive movement resulted in completely unexpected behavior. It is one thing to adhere to affordances provided by a digital medium, but it’s equally important to remember the real-life version. Whether it’s the paper version of a book or a magazine, when I want to read the next page, I flip the page over, left to right and not up and down. Both iBooks and Flipboard understand this paradigm for tablets and maintained it in their respective apps. I wish the New Yorker had done it as well.

2. Better Overall Issue Navigation

It’d be nice if I could either tap the top status bar to jump to the start of an article or a specific page in the issue.

The current “slider” offered by the “Viewer” provides a nice preview of each article, but why not combine it with the “page by page” preview so you can access a specific article or jump to a specific page? I wouldn’t separate navigation into top and bottom sections as currently offered. 

3. 100+ Mb Downloads per Issue

Broadband is faster these days, but that’s still not a good reason to warrant such humongous sized downloads.  It’s like getting a phonebook-sized edition of each issue.  The layout shifts a little between issues due to varying length of the articles, but overall, it’s pretty static.  So why is there ~130 Mb download for each issue? 

It appears to be a per-page snapshot of print version at a screen-readable resolution and saved as a JPEG. I’m assuming that this was attempted for a couple of reasons:

• Preserve the print version of the layout and font-type for “branding”
• Less work to produce a digital edition 

While adhering to the paper version’s layout and fonts is nice for branding, a regular reader like me would happily trade them for better readability and UX that’s appropriate to the medium I’m reading on.

4. Does the app have to crash every time there’s a new issue to download?

I’m almost certain that every time a new issue is ready for me to “view”, the app crashes. As I write this article, the app has crashed in each of the five times I’ve launched it. 

5. Concurrent Download of Multiple Issues

iOS supports multithreading when an app is a foreground process, and it allows several sockets open at once. So it is puzzling that the New Yorker app can only download one issue at a time. Additionally, if I’m downloading one issue and decide to download a second one, it conveniently pauses the first download, but never resumes it once the second one has finished. 

Continuous Revenue Stream from Advertising

The New Yorker should take a lesson from web advertising and dynamically serve ads even in old issues.

In order to achieve such a feat, I’d consider building the app with the 3 distinct pieces. The overall magazine layout is the only static part released with the app, while articles and advertisements are treated as two distinct pieces of content, fetched dynamically at a later time.

Separating the content types achieves two nice benefits at once. It improves the download footprint and allows for displaying fresh, targeted ads that change based on when an issue is being read as opposed to getting the original static ad that was published with the paper copy.  Imagine going through the archives to read an issue from ten years ago and seeing an advertisement for the Nissan Leaf instead of GM’s now defunct Saturn. The New Yorker could be capturing new ad revenue from old issues.

I’m very aware of the resource constraints that teams have to deal with in order to release software. However, translating what works well in the paper medium into the digital version with more thought to the native affordances would make the app a whole lot better and would lead my family to happily give up our paper subscription.