Closing Thoughts on Big Nerd Ranch’s Front End Web Class

I posted a few thoughts while I was attending the Front End Web class last week and I figured I’d put a cap on it with some final thoughts.

Disclaimer: If you happen to find this post and don’t know, I do in fact work for Big Nerd Ranch, so yes I’m partial but these are still my honest opinions.

Who is this class for?

Like other BNR books and classes, there is an expectation of some experience. You don’t need to be an expert by any means for this class but you should be comfortable with the basics of web design, hosting and how the web works. If you are looking for these beginner skills I’d recommend Code School and/or Code Academy.

With the basics taken care of, this class provides an accelerated but thorough tour of modern web development and the toolchains that you need to know. The class is great for people like myself, who have a history of web development but have been out of the game for a few years or mostly focused on the backend systems. Others who would find value include those who are looking to jumpstart a new web skill set for a new job or project.

Having a full week to escape the distractions of work and personal obligations really enables you to focus on the class at hand. Combine this with guided lectures and an experienced instructor to answer questions and discuss patterns, really elevates the value to “priceless”.

The Syllabus

The table of contents titles don’t really do justice to the details of each chapter. In total we build four separate projects:

  • The first had us work with HTML5, CSS and JavaScript to do a moderately complex layout of a slideshow like page that included animations, responsive layout and modern markup techniques.
  • The second project was a Coffee Order system the helped us use HTML5 forms, Bootstrap styles, and JavaScript to communicate with a backend via AJAX.
  • The third project was a chat app, that utilized web sockets. For this app we not only built the front end but the backend too, in Node.js.
  • The fourth and final project was an EmberJS app that would have us catalog monster sightings. Ember is a big framework but I think the book does a fair introduction. We got to work with a relationship of models, and executed all the big features.

I thought the chapter and project progression went really well. There are some who might prefer to end with Angular or React instead of Ember but the good thing to know is the early class concepts give you a great JavaScript foundation to build on so you’ll be empowered to experiment with all of those projects and more over time.

That is a core value of Big Nerd Ranch classes that I really agree with. They teach you from the bottom up so you can understand how things work and not just how to assemble/configure things.

The Extras

There is lots of open lab time at night. You are encouraged to bring a side project to work on. While I did make some progress on my own project, an Ember Wiki project (I have some basic models and forms working, all backed up my a Firebase persistence layer), I did have to dedicate some lab time to the book itself to make sure I kept up.

In the afternoons we’d have time for a walk around the resort and on some of the days we even arranged for a shuttle van to take us to some of the exhibits, like the Birds of Prey and the Butterfly Center. Considering how focused we are during the class, these excursions are very welcome and a great way to clear your head and get a second wind.

Final Thoughts

If you want to learn a new technology, in this case Front End Web Development, and in particular if there is a time-sensitive nature to your needs it’s hard to imagine a better environment than a Big Nerd Ranch class. The ticket price does include lodging and food for the week so keep that in mind when shopping around or putting together a formal company request. If you have any questions, feel free to contact training support. They’ll be happy to help you out.

31 Days, 31 Products: Sketch

Day 25: Sketch

This post is part of a larger series where for 31 days I’m posting a story about a particular product or service I’ve come to enjoy.

Sketch is a vector-based design tool for the Mac that is very good for people designing user interfaces.

I’ve owned Sketch for a while now. I’ve used it to mock up some UI and icons in the past but I’m not really an expert. I know enough to say I do like it and if you are interested in using it for interface design I highly recommend it.

I have a goal for the new year to become more proficient in Sketch. I’m signed up and really looking forward to attending the Big Nerd Ranch class on UI design in April. It includes teaching Sketch along side higher level UI concepts. I’ve also bought an online video course that I hope to start working through soon.

If you are at all curious I encourage you to download the free trial of Sketch and give it a go. If you like it, a license can be purchased for $99 from their online store.

iOS Mobile Design with Sketch at Big Nerd Ranch

I’ve wanted to get better at using Sketch for a while now and it looks like I might get my wish!

iOS Mobile Design with Sketch

At work we’ve revamped our mobile design class and it now includes learning Sketch alongside mobile design fundamentals. The class summary:

If you have basic design experience in UI, UX, web or responsive web design, this class will teach you to bring your designs to iOS in just five days.

In this intense week of learning about design for iOS devices, you will design an iOS app, from concept to delivery. With a focus on Sketch, you will learn a process that you can use in any future app design projects.

If this sounds interesting to you I highly encourage you to register and join us in January. I’m registered and really looking forward to the class.

Sweating the Little Details of UI Copy

While user interface design is not a core responsibility at my current job I do believe it is an important skill in my field and I try to improve all the time. A large aspect of user interface design is choosing the right words. For example, a good UI designer when crafting an iOS alert will honor and consider Apple recommendations. Some notes from the HIG:

Place buttons appropriately. Ideally, the button that’s most natural to tap should meet two criteria: It should perform the action that users are most likely to want and it should be the least likely to cause problems if a user taps it inadvertently. Specifically:

  • When the most likely button performs a nondestructive action, it should be on the right in a two-button alert. The button that cancels this action should be on the left.
  • When the most likely button performs a destructive action, it should be on the left in a two-button alert. The button that cancels this action should be on the right.

Give alert buttons short, logical titles. The best button titles consist of one or two words that describe the result of tapping the button. Follow these guidelines as you create titles for alert buttons:

  • As with all button titles, use title-style capitalization and no ending punctuation.
  • As much as possible, use verbs and verb phrases that relate directly to the alert text—for example, “Cancel,” “View All,” “Reply,” or “Ignore.”
  • Use “OK” for a simple acceptance option if there is no better alternative. Avoid using “Yes” or “No.”
  • Avoid “you,” “your,” “me,” and “my” as much as possible. Button titles that use these words are often ambiguous and can appear patronizing.

My personal pet peeve isn’t mentioned in the HIG but is present in almost all systems that require a user account:

Forget your password?

I hate that phrase. I find it to be patronizing and judgmental. As if I’m suppose to remember every password I ever created for every little web site and service. Who could?

Additionally, it’s misleading. If I click a link labeled “New Comment” I expect to be provided a form to make a new comment. If click a link to “Forget your password?” do I expect some flashy animated GIF that will erase some data from my brain? What I want is a link to “Reset Password”. The link title “Reset Password” is clear, focused on the target action to be performed and does not have a hint of judgement.

Sweat the little things. Read and then reread the interface guidelines. Be able to explain why for all your interface choices. Have fun.

Designing & Planning Your iOS App Workshop Recap

Workshops are a new effort from the Philly CocoaHeads group. Basic idea is: one workshop every other month, the workshop is a one day 5-6 hour event, that covers a single topic. Our first one was on Intermediate Objective-C and our second one, which was held last Saturday, covered Designing & Planning Your iOS App.

Kotaro Teaching

Overall the workshop went well. Kotaro Fujita was our main presenter and did a great job of alternating lecture and hands on exercise. At the end, attendees presented what they had worked on and how their app ideas were evolving. The crowd was great with lots of great feedback too. Some of my notes:

  • When brainstorming features consider using index cards or mind mapping software. I like MindNode Pro and Trello.

  • Spend LOTS of time wire framing, sketching, etc. Be mindful to separate your design time from your production coding time. It’s easy to fall into trap where you are coding things that will not work and this is very expensive. Way better to validate your designs with prototyping first.

  • Document what problem each screen is suppose to solve. Also document the emotions you expect the user to have. For example, on first launch what is your user asking themselves, how can you help educate them? Are you using verbiage they understand? How fast can you deliver your first WOW moment?

  • Get users involved as soon as possible. Preferably before you start to code. Should have some level of idea validation before starting.

  • Once you release a build, make customer support your highest priority. Answer every email/tweet within the hour. Let them call you. Doing this is a huge part of getting people to trust you and then later recommending you and your product.

Related Resources

In the spirit of the talk I wanted to share some other related resources.

So there are two great online courses going on right now regarding starting a startup people might be interested in:

Some of it is a little heavy on the VC-funding but otherwise lots of great things to think about.

Another video I find really helpful to watch and re-watch whenever thinking about which projects I want to work on: How great leaders inspire action by Simon Sinek. His explanation of “Why/How/What” is very inspiring for me.

For some design fundamentals consider reading Design for non Designers by Robin Williams and Don’t Make Me Think by Steve Krug

Finally I’ll mention the the Lean Startup Book which I reviewed back in 2013. It still is a favorite book of mine with some awesome ideas on working fast and based on validations and learning.


Did a short show and tell at the last CocoaHeads meeting demoing something I learned at work and hadn’t known about before, that being IBOutletCollections.

For seasoned Cocoa developers we all know that an IBAction is typically how a button sends a message to the controller that something should happen. On the flip side there is IBOutlet which is a pointer to a view in the UI that let’s the controller have access, typically to update the view’s contents or attributes.

Well an IBOutletCollection lets you have access to a whole collection of views via a single connection. In code declaring an IBOutletCollection is going to look something like this:

@property (strong, nonatomic) IBOutletCollection(UITextField) NSSet *textFields;

When you declare the type of the outlet you can be specific such as UITextField or use higher level classes like UIView and connect to many different kinds of views. Technically you can use NSArray but since the order isn’t something I think is guaranteed best to stick to NSSet. Finally, while most outlets should be using weak references, these use strong since the view controller needs to own the array that contains the connections.

When you want to iterate over the collection just use fast enumeration like you normally would with an NSSet.

- (void)updateUI
    for (UITextField *textField in self.textFields) {
        textField.text = self.mainTextField.text;
        if (self.isBlue) {
            textField.textColor = self.view.window.tintColor;
        } else {
            textField.textColor = [UIColor redColor];

For a simple project demo see my OutletDemo project on GitHub.

Some real world use cases for IBOutletCollection might include theming (outlet collections for various styles, then making connections to view that should be styled) as well as form access and validation. IBOutletCollection was introduced in iOS 4 so theres no reason not to check it out. Enjoy.

Week in Review: WWDC, E3 and CocoaHeads

It’s been a crazy week. Some random notes and observations…


Apple did a tremendous job streaming the Keynote. I watched it live on my Apple TV in the living room while chatting with friends on IRC and Twitter. It was awesome. As for the content, let’s review:

Mac OS X 10.9, Mavericks — Not a huge fan of the name. I liked Sea Lion! As for the user facing features, most are pretty meh for me, I will enjoy better dual monitor support. I also like the idea they are pushing iCloud Keychain and that it will suggest higher quality passwords for people. I myself will stick with 1Password but this is a great feature for users at large. The advanced tech of 10.9 looks great. Love the focus on battery life.

iOS 7 — I have very mixed feelings for the new UI. Some of it I like, some of it I don’t. Between the historic adoption rate of new versions of iOS and the complexity of delivering a consistent experience across iOS 6 and iOS 7, I can see many apps moving to iOS 7 only in the coming months, particularly ones that aren’t released yet.

While not reviewed in detail during the keynote, the real gems for me are in the developer tools and APIs released this week. Xcode 5 looks awesome. The new continuos integration services of OS X Server looks great (though time will tell if it can be a full on replacement for current solutions). Tons of brand new tech including: Text Kit, Sprite Kit, Game Controllers, UIKit Dynamics and better multitasking have been introduced along with some great improvements to current APIs. It’s going to be months until I have time to play with everything.

New Mac Pro — I’ve been a long time customer of the Mac Pro and was in the market for one in 2011 when I sadly, after continued uninspiring updates to the product line, had to settle for a loaded (max RAM / max Graphics Card / 256 SSD) iMac instead. Not to sound like a total dick, the iMac has been great and really fast but I still longed for the multi-drive, graphics card replaceable, mega ram slot tower that I was accustom to. So this new Mac Pro is actually in my eyes more of a loaded Mac mini style device. There is little chance you’ll be replacing these graphic cards (yes cards, it has two of them; probably to support the unannounced retina display this Mac Pro will probably ship along side with) and there doesn’t seem to be much room for extra internal hard disk space. That said, this machine’s stats looks awesome and I have been antsy for a retina display on the desktop. I’ll have to see a price tag before I commit myself but am happy I have options when it comes time to upgrade my current iMac.

There were also new Macbook Airs released at the show. I have and really enjoy my 13-inch Air and while the new extra battery life of these new models are probably very important for some people I am lucky enough to be able to plug-in when needed so will probably skip this generation. If it was a retina screen, maybe I’d change my tune.

Sessions — After the keynote, Apple, like they had promised, started publishing the session videos, usually less than 24 hours after they had been presented. By the end of the week we also had choices for HD or SD variants as well as the PDF slides. This helps take the sting out of not being able to acquire a ticket a lot and I thank Apple for putting forth the extra effort to do so.


I haven’t been keeping up with E3 nearly as much as I have been Apple news, but seems like everyone had a great time out in LA. Playstation 4 announced it will not be following Microsoft’s lead and is promising very little DRM on the PS4 that will inhibit things like game sharing and used game sales. This, plus a cheaper price tag and arguably better under-the-hood tech has pushed itself to the top the console food chain. Time and games will tell how things end. For me, I’m not planning on a day one purchase. I’d like to see how things pan out and find a must have game to push me over the edge.

As for my Nintendo, for which I always have a love/hate relationship with, we saw a new Smash Bros, a new Super Mario 3D World, as well as lots of new info on the new 3DS Pokemon and Zelda titles.

Moving from back to front, I’m getting pretty jazzed for the new Pokemon. Even outside my previous fandom for the series, this new release has a lot of new elements to check out. Being a huge Link to the Past fan has me interested in this new sequel game though I’m still mixed on feelings of curiosity mixed with disappointment that they aren’t doing something more unique. I own Super Mario 3D Land for the 3DS and it was not something I really enjoyed. The gameplay was very slow and continued use of the same old Mario platforming was exhausting. Considering the lack of interest New Super Mario Bros got as a Wii U title, you’d think they’d start to catch on that we need real NEW things but alas this seems lost on Nintendo. Finally, Smash Bros fans will inevitably enjoy a new release of Smash Bros. Even I get a little giddy seeing MegaMan added as playable character. Unfortunately I’m not a fighter fan. I no longer share a house with people to regularly play with and even when I do play these games at a party it becomes a button mash as no one knows all the moves. I think I’ve grown out of it. 🙁

CocoaHeads and our iOS 7 Hackday

On Thursday we had our usual monthly meeting for CocoaHeads. With the Apple event still in-progress there was lots of chatter about all the new stuff. When the meeting finally started we actually ended up with so many talks and demos we went over time. Reactive Cocoa in particular kept many a CocoaHead asking questions and thinking out of the box.

Saturday we held a hackday, our first CocoaHead event in some time. The hackday was focused on iOS 7 and had people work solo or team up to experiment with the latest API toys. Throughout the day we provided breakfast, snacks and a home made lunch from IndyHall’s own Kara LaFleur (@KaraLaFleur). At the end of the day we presented our results to the group and awarded book prizes from the Pragmatic Programmers and Big Nerd Ranch. All in all things went great and it was good to see some people attend who normally can’t make our nightly meetings.

Sunday Rest

It’s now Sunday and after an extremely busy week I’m relaxing. I do have plans to head out for some dinner later to wish my Mom to wish her a happy Father’s Day but otherwise am enjoying a lazy day around the apartment.

For all my Apple and gaming friends, I hope you enjoyed this week as well and enjoy the upcoming releases. Have fun!

Early Ember.js Thoughts

Over the last three weeks, I’ve been slowly picking up Ember.js while helping some colleagues with a project. It’s pretty interesting tech and I’d like to share some early thoughts.

What is Ember?

To be frank, I don’t think the Ember homepage does a very good job of explaining Ember. It features terms like “less code” and “developer ergonomics,” which are too much like “marketing speak” for me.

How I view Ember. Normally with a web app, you (as a user) will go page to page, sometimes viewing data and then sometimes editing data with forms. That’s what I’ll call a form-based web app. Sometimes you might want a bit of AJAX in these form-based web apps and, to get that, you’ll typically grab a DOM element and manually shove in a bunch of jQuery when needed, including direct commands and event callbacks. This process can work, but the more AJAX and client side stuff you add, the messier you can make things.

Then there is a class of web apps which work as one-page apps, where all interaction and DOM changes happen on the fly, without moving from page to page. Data is sent to and requested from the server in the background. Think of how Gmail and Trello work.

For me, Ember.js is all about giving you the toolchain to provide those types of dynamic, one-page web app experiences. Ember.js is a full stack, client-side, JavaScript-based MVC framework. The main objects you’ll work with client-side in the browser include:

  • Routers, which match the requested URL to controllers. They also ensure that the client URL is updated to allow the user to bookmark the different states of your app.
  • Models, to define your business nouns and store/retrieve user data.
  • Controllers, which handle actions and pass model data to the views.
  • Views to connect user events like clicks and taps to controller actions.
  • Templates to describe the HTML on screen.

Some Notable Features


If you’ve done AJAX work before, you might recognize that knowing what to update in the DOM can be a nightmare as the app state changes on a given page. Ember is particularly good at dealing with this, and as you build your HTML templates, the substitution hashes like {{ name }} for a person’s name not only are substituted for the real value on the first render, but everything is always kept up-to-date with an internal bindings system. This, combined with calculated attributes, really takes a lot of stress off the developer, in terms of keeping the app state in sync with the UI state.


For actually persisting the data, there is the ember-data project which will let you connect and map your client-side Ember models to REST endpoints. If you are using Rails, there are a bunch of gems that can really help to simplify this while providing all the serialization and API endpoints you’ll need. For more info, see this article.

Sharp Edges

As of this writing, Ember itself is version 1.0.0-pre-4 and ember-data is officially considered alpha quality. There is an upcoming Ember Camp, which hopes to see continued progress towards an official 1.0 release. Keep an eye on the Ember blog for more info. I do believe things have settled down to a point where there is value for people who want to get started with Ember and get their hands dirty. As to “production ready” — well, that will greatly depend on the needs of your application and your comfort with working around some sharp edges.

Getting Started

If you’d like to get started with Ember, in addition to the main website, which has some nice and ever-improving documentation, I’d also recommend:

If you are in Philly, also consider stopping by the local Ember Meetup.

Instapaper Gripes

First let me say that I really like Instapaper. It was one of the first apps that gave my iPad real purpose, and I use it pretty much daily. While the comments below might be negative and trite, there are tons of great things to love about this app too, so don’t take things too seriously. If you aren’t already using Instapaper, I’d recommend reading the the MacStories review to see what Instapaper is all about.

A lot of these gripes are based on personal usage (described early in gripe 1) that, in theory, mirror large scale usage. I’ll be the first to say that I could be way off on that. I’m not currently aware of whether Marco captures the kind of usage data that would help him evaluate the effectiveness of the Instapaper user interface, or if he has ever made those numbers public.

The big idea here isn’t to gripe on the Instapaper app for the sake of griping, but I want to start discussing interface design, the tradeoffs we make, how design evolves, and so on. I figured this post would be a good place to start, since I am unhappy with some of the choices made in Instapaper, despite the fact that it is a really good product.

Aside: Gripes, while numbered, are not sorted by importance.

Gripe 1: Always showing the collection chooser is a waste of space.

When you first launch Instapaper, you’ll be taken to the Read Later collection. Before I talk about that collection, let’s talk about overall layout and navigation.


This view tries to accomplish two things at once. First, it’s a collection chooser (overlaid in orange), which lets you switch the collection you are currently browsing. Second, it’s a collection browser (overlaid in blue), which lets you browse the articles of the selected collection and load an article to read.

I’ll take a stab in the dark and say that I am an average Instapaper user. My Instapaper usage is as follows…

Each week I’ll see various articles on the web shared to me via Twitter or mentioned in email. I’ll mark them as Read Later using my desktop browser’s bookmarklet or the built-in Send to Instapaper features of apps like TweetBot. I probably send anywhere from 15 to 25 articles to Instapaper a week. When I do find some time on the couch to read, I’ll open up Instapaper on my iPad. The collection I’ll be browsing is always the Read Later collection. I have to imagine this is the same for most others as well.

If this is true, and the majority of the user’s time is spent in the Read Later collection, I cannot understand why the interface has been designed to dedicate 15% of the screen to collection choosing, which is not something that is common in typical use. I feel like giving this space back to the collection browser, along with some ideas on improving the preview cells of articles, could greatly improve the browsing experience on Instapaper.

Coincidentally, TweetBot for iPad has a similar, always present, sidebar, but here it doesn’t bother me nearly as much, since I do frequently use it to switch collection contexts. With Instapaper, the collection chooser is, for the most part, just dead space for me.


Gripe 2: Centering the title in the collection browser looks misaligned because of the system clock.

Can not be unseen.

Alignment Why?

And, yes the TweetBot screen has the same problem.

Gripe 3: The “grid” default collection layout style is questionable.

I know there are many popular grid-oriented apps out there for presenting content on iPad. For me, I find the use of the grid in Instapaper to be more of a distraction than anything. I don’t like the flow of my eye path as I have to browse the collection in a grid.

Grid eye path

I’d much prefer a purely stacked list of article previews. I feel that this eye flow is better, and, as a bonus, it has great synergy with the vertical scrolling motion.

Thankfully, there is an option to toggle this behavior in Settings. I don’t think it was there immediately upon 4.0’s release, as I vividly remember not liking the grid and not seeing a way to turn it off, but sure enough, I found it while I was prepping this article. Woot!

Aside: The launch image always assumes a grid so on a fresh launch it looks a little clunky to see the grid and then see it go away in favor of the users preference. It’d be nice if the launch image were made more user preference neutral in the future.

Gripe 4: Different collections should have different preview cells.

There are many different collections, but only one basic cell design for the article preview cell. I find this unfortunate because the user’s goals when exploring the different collections are quite varied and could benefit greatly from expanding the different cell preview designs. It would be great if Instapaper could offer some user preferences to suit their needs. Some examples:

Preview Cell Design for “Read Later”

Scenario: I’m browsing the Read Later collection from my couch. I have an hour to kill and want to catch up on things. The sort of the Read Later collection is based on when I added articles, so I’ll see the most recent at the top. My goals for this view are:

  1. to remind myself about the article I added
  2. to determine whether I want to read it now

To remind myself, the preview cell offers a mix of article title, source domain, author, and a short blurb. For me, the blurb is usually overkill. It could be subbed out for more useful information.

While very helpful in reminding me about an article, the preview cell does very little to help me determine whether I should read one article or another. The cell does provide a series of dots which, if you use Instapaper over time, you might come to realize represents the length of time that the article will take to read, and how much of it you have already read. Personally, I’d like to see that changed into a more descriptive, text-based description and drop the “percent of article read” feature. After all, to do it in text would be verbose, and I’d like to think that the majority of users read these web articles in one sitting (again, I don’t have numbers on this).

What I’d really like to see is Instapaper start to take advantage of the friends I’ve added to it and the global data it has, in order to help me realize what of the things I’m browsing is worth my limited time. Which articles have been liked by my friends (show me a few of their tiny little avatars) and what articles are making an impact globally (using global read and liked counts)?

Preview Cell Design for “Liked”

Scenario: I would assume that one of the main reasons I’d be in the Liked collection is because I’m trying to find an article I’ve read and Liked previously. I probably want to reference it myself or send it off to a friend. For me, this would usually involve searching, but I’m going to wait to talk about that later. As for the preview cell design, again we see the same design used in Read Later. How to improve?

In a word, dates. If used often, the “Liked” collection will span months and months of articles. Knowing when an article was published and when I Liked it would help me find what I’m looking for during a browsing session.

Preview Cell Design for “Archive”

I feel like the design for the preview cell in the Archive collection should be a hybrid of my proposed Read Later and Liked preview cell designs.

I also think that the Archive collection (as well as maybe Liked) might do something to help group up articles I’ve read by the same author or from the same site.

Preview Cell Design for “Friends”

More than improvements to the the preview cell, what this collection really needs is a list of my friends. Show me who is actively reading and linking stuff. Let me browse their history, as a collective or as individuals. (I go on about this in more detail in gripe 9).

Gripe 5: Archives and Liked collections should load more articles as necessary.

For what are probably many valid reasons, Instapaper only loads a small portion of your Archive and Liked collections. When you browse to the bottom of these collections, it just stops. If you want to load more, you need to visit settings and tell Instapaper to load more articles for these collections. This seems clunky and non-intuitive to me. There is nothing at the bottom of the list to even suggest that you should go to Settings in order to see more articles.

What I’d prefer to see here is some sort of button that allows users to manually load more articles, or perhaps Instapaper should passively load more by making an endless scrolling list.

Gripe 6: Respect my eye line.

The article view does a great job of letting the content own the space. There is a navigation bar, but unless you interact with it, it will eventually fade away while you read.

Article View Navigation

There are two ways to bring the bar back. One is by tapping somewhere that isn’t otherwise interactive. The other is by scrolling to the bottom of the article — this is my gripe.

When I read articles in Instapaper, my eye line or reading zone (shown below overlaid in blue) is the very top of the screen. I literally read 1-3 lines and slowly scroll the page up little by little when I’m reading an article.

Reading Zone

Eventually, I’ll be almost done reading the article and — BAM — the navigation bar comes up and covers my reading zone. What follows is an unpleasant scrolling dance that I don’t even want to describe.

I understand that it makes sense to automatically show the navigation bar towards the end of the article, but the algorithm needs to be tweaked in order to make sure that the reading zone of the user would never be hidden by the navigation bar, which, from my experience, it clearly can.

Gripe 7: Questionable archive icon and popover menus.

When you finish reading an article, part of the reason the navigation bar comes back up is because you have an action to perform:

  • Like the article by tapping the heart icon.
  • Archive the article by tapping the trash can and choosing “Move to Archive”.
  • Delete the article by tapping the trash can and choosing “Delete”.

Archive Menu

I feel like the choice of a trash can for the non-destructive action of moving an article from my Read Later collection to the Archive collection is unfortunate and likely confusing to some new users. Trash cans in a computer context mean “I never want to see this file or object again.” A trash can is not a suitable icon for transferring an article, even if the destination is an archive. Ultimately I feel like each of these three actions should have their own icon and remove the popover entierly.

Aside: One alternate way this plays out is if you Like an article first and then tap the trash can the Delete action is removed leaving only Archive. Why would you ever want to present a popover menu where there is only one action? Again my recommendation would be to drop the popover entirely but should a case like this come up just assume the one remaining action and suppress the popover.

Gripe 8: Search is too elementary.

Search in Instapaper works like this: there are various search buttons in the app, and when you tap on them a modal window pops up. Then you type in some terms and a search is done against the full text of all the articles you have in Instapaper. The search happens on Instapaper’s web servers. The results are presented in a list and then, upon tapping an item in the list, you jump to another modal window with the webpage of the article.

Search UI

There are many problems with this experience:

  • Search requires an internet connection. There is no way to simply search the stuff you have locally.
  • In order to accept the search terms and present a result list, Instapaper uses a modal view that fills only 50% of the screen. Half the screen is left underutilized. Why is this not happening inline in the collection browser area, as I would have expected?
  • There is no way to control your search context. The only option is “All.” For example, you cannot do a search for something in your Liked collection.
  • There is no way to reorder the results; they are presented in an unknown order. There is no way to sort specifically by the liked on date or search term relevance.
  • When interacting with a result, the article is presented in a modal webview instead of the expected Instapaper article view. One of the major points of Instapaper is that it filters out a website’s frame for easier article reading. Why not a proper article view here?

Overall search comes off as a minimum viable shipping feature, good enough to ship, but not where it should be. If it were just a young feature that would see improvement over time, I wouldn’t gripe as much, but search is actually the main unlock if you choose to pay extra for a monthly Instapaper subscription. In that context, I really think it’s important that search sees improvements soon. I don’t think it’s right to reward subscription buyers with such an elementary feature.

Gripe 9: The friends collection

Another young and hopefully to-be-improved-upon feature is the social aspect of Instapaper. The current version allows you to connect various friends, but the interface can be pretty clunky at times. For example, you have to add friends with one view and then remove them with another. Why does this require two views?

Add/Remove Friends

However, the real problem is the collection browser itself.

As I’ve said before, I really think this view needs to include the avatars of the people who are sending me this content. I know people by their avatar a lot better than by their twitter handle, and this change would make visually browsing things much faster. Also, I want the power to isolate a friend and just see what he or she is promoting. Let me browse by my friends, and then browse what they are sharing specifically.

At the bottom of the Friends collection is a toggle to show “Shared Links” or “Liked by Friends.” First off, it’s really awkward to have a toggle between a noun and a verb. Something is amiss.

What does Instapaper mean by “Shared Links” — these objects are called articles everywhere else in the app — why the difference here? Best I can tell, “Shared Links” represents URLs that people have posted on Twitter, Facebook, Tumblr, and other services. I get that there is a naming challenge here, but I am not really happy with the current solution of “Shared Links.”

In fact, I truly wonder if there is any value in having two distinct sub-collections in the friends category. Why not just one collection, and make it clear in the preview cell how this article came to the reader, i.e.: “Liked on Instapaper by Manton Reece @manton” or “Posted to Twitter by Thomas Fuchs @thomasfuchs?”

I think this, plus the power to browse and isolate content per friend, would be a nice improvement.

Gripe 10: Drop “The Feature” collection.

Described at the top of its view, The Feature is:

Daily editorial selections from the finest articles saved with Instapaper.

I never use this feature/collection. I have enough content to fill my reading time, and the idea of reaching out to this specific collection of content seems strange.

It’s unclear how many articles are posted per day. The blurb says “editorial selections” as if to say, “these aren’t selected by robots,” but then no human editor names appear either. Who is the editor? What makes these articles so “fine?” What is the focus here?

When I click on an article, it doesn’t even load a standard Instapaper article view. Instead, it loads the website. Why would it do this? For me, Instapaper is about an offline, clutter-free reading environment. This provides neither. It feels like an ad.

Maybe I wouldn’t gripe as much if this collection didn’t stare me down every time I opened the app. It just sits there in the static collection chooser area, which I never use. I wish I could turn it off.

Gripe 11: Settings

When I tap Settings in the lower left corner, I get a popover that is about 1/3 the height of the inner view (thus I need to scroll to see everything). Every other navigation-based item in this app has made use of the full screen of the iPad. If Instapaper didn’t have an iPhone version, is this how the Settings view would have been designed? I doubt it.

Settings Popover

The Settings view should fill the screen and fit in with the visual style of everything else, probably as a collection browser if the static collection switcher style design is staying. With this extra space, you can be more specific about things, like using labels as well as icons for the various friend services.

Gripe 12: Android

First I want to say thanks to Instapaper for doing an Android version. It was very handy to have a portable tablet version of Instapaper around when iOS 6 bugs were making my iPad less than useful. I will gripe however, that on Android you are not always following along with the Android-isms. For example, I found the behavior of the hardware back button to be somewhat inconsistent. Android apps should feel like Android, and iOS apps should feel like iOS.

The biggest problem with the current Android version is the lack of scroll position saving during orientation switches, which for me are usually involuntary as I move my Nexus 7 to reach for a glass of water or something. I’ll come back and my article is not where I was. Very frustrating.

On Gripes

Again I’ll say that I really do like Instapaper, both the service and the apps overall. My gripes are meant as feedback and kickoffs for other user interface discussions. Please do not take offense.