This past weekend I built a DIY time-lapse dolly. Here’s an edit containing all of the tests I took while working on it. Still some smoothness/operator-error issues to work out but I’m really excited about the potential.
Timelapse Dolly Prototype - First Run from Nate Weiner on Vimeo.
As Marco has opened up on the matter, I think it would only be fair to do the same.
Instapaper is a competitor to Read It Later. It launched as a web app few months after I launched my Firefox extension.
If you’ve ever spoken with me about Instapaper, you know that I do not consider Instapaper a competitor. While we certainly attempt to solve the same goal, we take completely two different approaches in doing so. In the last year alone, I think we have done a miraculous job at innovating away from each other in what seemed like a very small space. Depending on your workflow, each offers features that may suit you better.
I have no fear in saying that because I fully believe in the product I’ve built. Moreover, Instapaper’s success vs RIL’s does not matter and let me explain why.
Twitterrific, a Twitter client, recently responded to an RIL user requesting to add RIL support. They responded to say that 95% of their users don’t even use Instapaper. The thing is that 100% of those users probably should be. RIL and IP are services that when you first learn about, just do not seem to be worthwhile. But they solve a problem that EVERYONE has. Once you close the 10484503 browser tabs you have open, clear out the random links in your inbox that you’ve emailed yourself and start finding that they’ve all been culled into one nice little list that follows you everywhere, it starts to make a lot more sense.
It’s this massive group of people (I believe they are called the mainstream) that defines why Instapaper does not matter to Read It Later and Read It Later does not matter to Instapaper.
Let me illustrate this with a trusty pie chart:
The fact of the matter is, RIL and IP are not deadlocked into a fully utilized market (for example like Firefox vs Chrome vs IE). The amount of people that have never heard of either of us is staggering and offers plenty of space for each of us to play in without getting in each others way. And as we both grow, every time someone hears about one of us, they are likely to hear about the other. So until the market is maxed out, the growth of one benefits the other.
The simple fact is, even if RIL claimed 10% of what potential there is out there, I could afford to buy NASA and have them build robots that did my job for me. I’d be okay with that, even if Marco had 15% and was able to afford cooler robots.
From the way I’ve seen people talk about Read It Later and Instapaper, it seems that everyone assumes there is some major bad blood between us and that you have to pick one side and hate the other. This just isn’t the case. Marco and I are just two solo developers trying to make something we think is awesome. At the end of the day, it does not matter which one you pick, all that matters is you supported an indy developer and made it possible for them to make a career out of building things they love. I’ve got nothing but respect for Marco and I’m confident that we’ll continue to ‘compete’ with the same mutual respect till the end. (aka the robots we built turn on us)
Apple has posted a number of videos that walk through each of the default apps for the iPad (via Macstories). They are worth a watch. Being able to see the iPad in action reveals a number of little details.
A nice touch in Safari, when you tap the location bar to start typing, a bookmark bar (like in desktop Safari) pulls down.
The Safari video also answers one question I had long wondered. It looks like you’ll be able to watch embedded videos inline without having it pop open the YouTube application. I’ve always found that flow on the iPhone really disorienting.
Watching the video on Keynote really makes it clear that using a keyboard and mouse to do any type of design work is going to feel incredibly antiquated in the very near future.
I cannot wait to get my hands on one Saturday.
Side note: The icon the iPad displays on screen when you lock the rotation (shown in the iBooks video) looks awfully familiar. I know, but it’s fun to pretend they did 
Of all the possible scenarios we (developers) considered for exactly how Apple planned to roll out iPad apps with the release of the iPad, this was the one I dreaded the most.
Apple is now accepting iPad applications to the review process. If you submit before March 27th, you may be included in the grand opening of the iPad App Store.
The only problem? No one has an iPad yet and won’t until April 3rd.
Anyone who has developed on the iPhone SDK knows that how an app runs on the SDK simulator can be night/day vs how it runs on the actual device. Even if it runs flawlessly on the simulator, I’ve never had an instance where the first time I ran a new app on the device it worked to my liking. There are bugs and crashes that didn’t occur on the simulator, there are slowdowns in areas that you thought were fast, and usability changes you didn’t expect.
So we are now faced with a risky decision: go for fame and fortune, submit an app and cross your fingers that it actually works or wait, miss the hoopla, and submit something you KNOW works.
I really wish someone (probably Apple) would standardize a way to describe iPhone/iPod Touch/iPad apps in one word.
When you talk about apps for other devices you simply say: it’s an Android app, Blackberry app, Mac or Windows app. You do not have to specifically list all of the devices that the application works on.
You could simply say ‘iPhone (OS) app’, but because this language is specific to a device, it can easily lead to confusion. The last thing a developer wants is for an iPad user to see there is an iPhone app available and not make the connection they can purchase it for their iPad. This arguably was less of an issue between the very similar iPhone and iPod Touch, but once the iPad drops into a whole new market, this will be even more confusing for the end user. This is why you see a lot of the lengthy ‘iPhone/iPod Touch/iPad’ strings when describing an iPhone OS app.
When trying to design a clean and concise layout, it’s simply too wordy, too ugly. For example, on Read It Later’s home page, I have links to all of the platforms that RIL is available on. You’ll see I have ‘Add to iPhone/iPod’. I’m not looking forward to squeezing in ‘iPad’. Same problem with the main navigation at the top where I list the major platforms: ‘Firefox, iPhone, Mobile, All Browsers’. When designing that I gave up on including iPod, but now that the iPad is imminent, I feel like it will need to be squeezed in there as well.
I’ve had some time to think about today’s release from Apple, the iPad. I’m finding that the more I think about it, the more disappointed I am. But I know why: The iPad was not created for us (and by us I mean the tech crowd).
Take a look at today’s release. Remove all of the changes to the software and the new iWork/iBook products. If you look solely at the hardware and the device itself, there is nothing revolutionary here. There are no revolutionary new input methods, no new integrated additions (like the compass was to the 3GS and the camera to the Nano) and nothing new in form factor (aside from size).
Now look at the software. While the default apps like Mail, Safari, Photos, and Calendar got a refresh, the OS itself is fundamentally the same. The home screen simply has more space in-between the icons and a background image. In fact, even though you have a bigger screen, you still have the same number of icons per page. There is no multitasking, no OS-wide gestures, and no major APIs opened to developers.
The problem is the tech community expected to see iPhone OS 4.0 today. We expected to see something we hadn’t seen before.
All Apple did today was release the same product they already have, only bigger.
And you know what? It’s going to work.
The iPad is targeted towards all of the users who simply need a device to browse the web, check email, watch videos, go on Facebook, and play a little Farmville. And as Apple knows, this market segment is a LOT bigger than the ‘I need multi-tasking and Minority Report style input’ crowd. I bet that for the majority of people in Yerba Buena Center today, the iPad will not be their mainstay machine. Most of them will buy it, play with it, or develop on it, but most of our computing will be done on laptops and desktops.
The iPhone and iPod Touch have been incredibly successful. If Apple released a new device today that required a steep learning curve with revolutionary input controls and a new OS unlike anything we’ve seen before, your mother would not care. Your non-tech-savvy friends would not use it. What Apple is doing is simply taking something that works very well and making it reach a little farther.
So what I’m really disappointed about is how much I got sucked into the hype cycle this round. I’m actually really excited to read, watch, play, and develop on this device. The iPad is a going to be a great device, it’s just not the technological savior we were looking for. Still, as I look back at all of the really amazing things we all hoped the iPad would be, I realize that these ideas are now out there. It may or may not come from Apple, but now it’s just a matter of time.
Trust me, I know how badly the App Store’s review process can burn you (*Ahem*). In fact, while I’m on the verge of trying to push out Read It Later 2.0 as the busier holiday season approaches, I’m expecting even more frustration.
Since Joe Hewitt quit the iPhone platform, a strong discussion has emerged and a lot of good ideas have been surfaced. However, one bad idea that both Apple and I know will never happen is: ditching the review process all together.
Over the last few weeks, people have talked a lot about how the review process is bad for the open web. What I think is interesting about this concept is that the one company I believe is probably the most open of all, Mozilla, has a review process for extensions. All of those free, open extensions you have in your browser? Those go through a far more rigorous review process, have their actual source code looked over, and sit in a line generally longer than the one at Apple. Yet, even though this has been happening for years, I would bet no one has heard of any controversies there.
I know this because of my time building add-ons but also because around the time of Firefox’s 3.0 release, I was an AMO Editor (extension reviewer). (Technically, I still am, but have simply not had the time to volunteer recently.)
The review process is absolutely necessary. Mozilla’s reviews stop a LOT of junk from getting through to the end user. When you browse the AMO directory, you can be assured that every add-on in there is useful to some purpose and more importantly, it’s safe. It’s not going to steal personal data, it’s not going to install additional programs or do anything not clearly described in the description.
Mozilla’s process, though longer and more in depth, differs from Apple’s in only a few ways. Yet, these make all the difference between controversy and satisfied silence.
Anyone can submit an add-on to AMO (Mozilla’s add-on directory), it will appear immediately and be available for download. However, this add-on is flagged as ‘experimental’ and when the user views/tries to install it, it warns them of the potential consequences of using untested software.
After the add-on has been submitted it can be nominated for public status. There are a number of criteria your add-on must meet in order to be considered. Overall your add-on has to be useful to a wide portion of users, well tested, and has been received favorably from those who have tried the experimental version.
Once it’s been nominated, it enters the review queue for an AMO editor to look over and eventually reject/approve it.
This means that anyone can get into the directory immediately and start having people try their add-on. Once it’s flushed out further, they can push it through to the more public, much more lucrative (download wise) public side.
If it’s an add-on that is only useful to a small number of users, it will stay as experimental and won’t clutter up the main AMO directory.
If you send an email to the AMO editors, you can almost always expect a response within a day. I am still on the email list for the editors address and from time to time check in, but I always see the editors responding quickly and generally with helpful information to answer the developers question. Often there is thoughtful conversation between the editors trying to determine the proper response before replying.
This is the most important factor in a successful review system. A developer should be able to get any and all questions answered in satisfactory way as quickly as possible.
In the way that Apple works, it’s generally pretty difficult to illicit much response from their blackbox. In the past year I’ve sent several emails over to Apple’s side and was often met with silence or in one case a month long delay before a response. This is unacceptable.
I will say however, the most recent email I sent to the review team was replied to within 17 minutes. Though the response was short/vague it may mean things have certainly improved since earlier this year.
When an add-on is rejected, you receive an email with the reason why and the name of the reviewer. Generally, if the reason for rejection was something that can be fixed relatively quickly, you can email that reviewer back, say you resubmitted the fix and they’ll take another look at it. You won’t have to restart the lengthy wait to be reviewed for something that took you 10 minutes to correct.
This is one of the loudest complaints you’ll hear from iPhone developers. If you wait in line for 2 weeks and then ultimately get rejected for something as minor as an icon, it’s incredibly frustrating to have to start all the way back at the beginning of the queue. The 2 week long wait will seem a lot less unbearable if you know you can still get approved given a minor oversight (or problem with policy).
Mozilla’s system is far from perfect. It also suffers from one of Apple’s biggest problem in that updates to existing add-ons can take a while to get through the queue. However, the responsiveness offered by AMO’s team, means that if you are rejected for something arguable or minor, that you can still get through just after a few emails and a few changes to your code.
Apple’s current process is running on ground that cannot stand for much longer. The number of apps is growing rapidly, and unless they hire hundreds of reviewers, it’s unlikely that all of these applications are getting thorough testing. From what we, as developers, have seen is that the review generally lasts a minute or two. From stat tracking to server logs, a lot of developers can see that the reviewer doesn’t even use all of the functions within the app. If this is the case, then the usefulness/stability of the apps appearing in the store are a lot less credible.
They have over 100,000 apps in the store, but let’s be honest, a huge number of those are crap. It would be far more useful to the end user to have an app store that had less apps, but higher quality than vice versa. By implementing some sort of intermediary (like Mozilla’s experimental stage), they could offer developers a place to stand on their platform while being able to dedicate more time to those in the main app review process. More time means, better reviews, more responsiveness, and less of a wait time.
The App Store review process certainly could use some improvement, but we need to accept that it’s there for good and push harder for smarter changes to improve the review process, rather than waste our time trying to abolish it.
Today, I am taking on Read It Later, iPhone development and Idea Shower projects full-time.
Two years ago, I worked for a small web design agency in the Twin Cities and on one random night after work I built a little project. A few months later I decided that I really liked making these little projects and made the call to leave my job and focus more time on my projects while doing contract work part time.
But as the last two years have gone by, in order to make a living, I found myself working full time on contract work and having little time to apply to my own ideas. And again, two years later, I have found myself seemingly in the exact same place again.
However, this time, one thing is different. That little project I started 2 years ago has started to do something I never planned on: it started making money. It’s not enough to quit working and live on an island and it’s not enough to cover my previous contract income, but it is enough to make me believe that I can finally get to where I wanted to be all along: making a living from users, not clients.
It is not going to be easy. Yet, as nervous as I am to take this risk, I’ve found that in my short 25 years on this planet, I’ve never regretted doing something. My only regrets have ever come from not trying something. In the end, if I fall, I can pick myself up and try something else.
Idea Shower is coming back. I’ll be launching the 2.0 version of Read It Later (which is going to rock, I’ll have you know), and then I’ll be moving onto 3 other projects I plan to launch within the next 6 months.
Stay tuned.
As I watch the receipt start printing, I always have the same thought in the checkout lane: “Why?”
That piece of paper the clerk is about to hand me is going to get shoved into my pocket and is going to end up god knows where. My desk, in my mail stack, in the lint trap, or discovered next winter when I pull my jacket from the closet again. No matter it’s destination, it will have lived a fruitless life, serving no purpose but to clutter my life.
A growing number of stores are beginning to ask the question: “Would you like your receipt?” But the overwhelming majority still happily prints you this waste of paper.
Though these point of sale encounters vary, there is generally one common element: a place to run your credit card.
I rarely carry cash with me anymore, paying with a credit card is far more convenient. And generally I am only using one card for all of these different stores. What I’d like to see is either on the store side or ideally at the credit card level, a way to set your preferences for receipts and even bags.
What if the system knew when I swiped my card that I did not want a receipt? I would not have to wait for it to print and I could be on my way with one less thing to throw away.
In the app store, it is very common to find that paid apps have an accompanying free or lite version. It’s a great way to let users get a taste of an application or game without having to blindly purchase it.
It’s so common that often when I’m browsing through the store and I find a game or an application that looks interesting, I’ll open up the search tab and look to see if they have a free version to try first. This has saved me from spending money on some terrible games but also has lead me to purchase a ton of games that I got hooked on using the free version.
Since this has now become almost a standard for a lot of applications, I think the App Store can do a better job at bundling these free and paid versions together. I’d like to skip the extra steps involved in having to seek out free versions whenever I find a cool app while browsing the store (especially in the new Genius section).
If developers were able to link free and paid versions together through iTunes Connect, Apple could then display a small shortcut on the paid version that lets users know there is a free version out there to try. Even a small ‘Try It’ button underneath the purchase/price button would save a lot of hassle.
It would benefit users by allowing them an easier way to try out applications before dropping money on them. It would benefit developers by giving them one more chance at hooking a customer who might have otherwise balked at the price at first.
One Touch Rotation Lock on the iPhone
How to Make Simple Cross-Domain Ajax Requests With Responses
Remember Just One Password That’s Unique For Every Site
