Philadelphia 2035 Cliffs Notes Edition
No, not THAT Cliff.
The City of Philadelphia just published a ~25 year plan, the first of its kind in half a decade.
While I’m not one for that style of long-term planning, it’s remarkable as a short-term planner with long-term vision to know what’s going on inside the heads of City Hall. The problem?
It’s a 200 page, ~40 megabyte PDF. Link to PDF.
A nicely designed one, I’ll give them that, but gosh what an unfortunate side effect of such large scale planning. Don’t they know that I spend my days reading blogs and tweets? 200 pages is basically an encyclopedia to me. And I’m sure I’m not alone.
I joked on Twitter that documents of this size should come with “Cliffs Notes” (I thought they were Cliff notes, didn’t know Cliff himself had been taking notes all those years). Then I thought that could actually be kinda fun, to get a group of caring citizens in a room to analyze and synthesize the documents contents from multiple perspectives, and write it all down into a cheat sheet size version of the document so we can more easily discuss the more important side of the plan: the execution.
I think this might give us some ideas on things we can do as citizens to help give the city a head start on its own plans.
I’m not 100% sure what the format for dissecting the document would be just yet, but I’m thinking some mix of a mini Barcamp + Hackthon + something else entirely.
Anybody interested? RSVP and add ideas for how to keep this organized in the comments.
My goal is 90% compression – 20 pages of only the most critical information. Many skills and talents will be useful to accomplish this – designers, developers, writers, people experienced in various components of the city and city planning would also lend lots of great perspective to the process.
Just no jerks or whiners.
Lets check personal agendas at the door and just produce something that will get this important information into more peoples’ hands.
This could either be the best idea I’ve had in a while or the worst idea. Let’s find out together.
RSVP, see you Saturday. Looks like a bunch of people who want to attend can’t make it tomorrow, so I’m moving the event. New times/dates to be announced. You can still RSVP with interest and to get notifications of new working sessions! Thank you everyone for your interest!
Find out details or sign up below. Save $75 by using the code DANGER.
A Story of Discovering Potential
Just over a year ago, Parker Whitney showed up at Indy Hall during our search for an intern.
He was wild-eyed and excited, curious and free-wheeling. He had a psychology degree but no particular aspirations for it. He wanted to design t-shirts and play video games. He wanted to see Indy Hall first hand, experience Indy Hall first hand, and make it part of his home in Philadelphia.
At that point, we needed someone to help take some of Dana’s workload on, and ended up supplementing her with 2 interns, Parker and Michelle. Michelle left us shortly after, having quickly found her way through the community to an opportunity working with artists, what she truly aspired to do. Parker stuck around to continue to find his place.
I’m glad he did.
In the last year, Indy Hall has become more self-sustaining than ever before. Parker took on a role that is more significant than I think either of us expected: while I was away from Indy Hall for the majority of this year, I did so in confidence because Parker was not only capable hands behind the desk, but a strong communicator and he truly understood not just what Indy Hall was, but why it was.
He threw himself in headfirst and on his own terms, he tried, tested, learned, and loved. He also brought his own off-beat humor and care to the details around the hall, and quickly became a crowd favorite at Indy Hall.
Parker’s contributions, along with many of our members, are a large part of what kept Indy Hall growing strong this past year. I’m thankful for that, but most recently, he really made me proud.
A few months ago, Parker teamed up with another Indy Hall member, Jake O’Brien. Jake is an iPhone developer, with a few successful games already in the App Store, and quickly took to loving Indy Hall for his own reasons. He and Parker began kicking around ideas for mobile games, and Jake helped Parker realize that together, they could actually make those ideas real.
Parker had learned some Adobe Illustrator skills from other members at Indy Hall, and when matched with his love for drawing, figured out how to design assets for an iPhone game. Together, he and Jake worked out the game mechanics for a simple but ridiculously addictive game called Brain-a-rang, where you kill a fast-approaching horde of zombies with different kinds of boomerangs. It’s $0.99 and you should probably buy a copy.
Parker’s off-beat style shined through on this game, down to the hilarious voiced sound effects he recorded, and after several weeks and late nights of working together, they launched the app.
In less than 12 months, Parker, who had no idea what he wanted to do, found a way to do something he thought he couldn’t EVER do: make a video game.
But our story doesn’t end there: during a recent routine tour of Indy Hall with a prospective new member, they found out that Parker had experience designing iPhone games. Before they knew it, Parker and Jake were in the throughs of their first contract together as game designers and developers for hire.
Just a couple of days ago, I wrote about where I think jobs come from. While the US economy is still in a rickety state, the story of how Parker came to Indy Hall, explored, tried, made friends, and then created a job for himself is an illustration of why I think places like Indy Hall are important. Parker saw this, and seized this.
This is more than “entrepreneurship”, which I’ve noticed tends to be a self-assigned label. I don’t think Parker would call himself an entrepreneur, though reading the story above, some others might. What I do think is interesting is that this process of self discovery and the realization of potential seems to be at the core of most successful entrepreneurs, though its a story less told.
In Parker’s story, there’s an element of learning from seeing, and there’s an element of learning from doing. Indy Hall allows both kinds of learning to happen simultaneously, complimentary to each other, which I think increases the likelihood of otherwise unlikely happenings to happen.
Find out details or sign up below. Save $75 by using the code DANGER.
Better Ipsum
Working with the team at Red Tettemer has been about seeing the “little things”.
Today I decided to add one of my own little things by replacing the typical Lorum Ipsum that we splatter across our web pages before we get content for them with something a little more…infectious. I mean entertaining. I mean fun.
Since we use Textmate whenever we’re not elbows deep in Flex Builder, it seemed like a quick and obvious place to start, creating a Textmate Bundle that adds the Tab Trigger for the word “ipsum”.
Simply download and install this bundle, which I’ve decided to name BetterIpsum, and try it for yourself. Never more be plagued by barely pronounceable latin garble, and instad, get a tune in your head that you won’t be able to get out.
I’m thinking about creating a TextExpander version of this to make it less IDE dependent, but only if people are having as much fun with this plugin as we are at Red. And if there’s a way to do this for Photoshop (macros, I suppose?), I know our designers would love it as well.
Find out details or sign up below. Save $75 by using the code DANGER.
Mailroom: Gmail on the iPhone for Busy People, built by Busy People
I’m a heavy Gmail user, with 6 (soon to be 7) separate Gmail and Google Apps accounts. On my Macbook, I actually IMAP in to all of the business accounts using Mail.app for one reason: cross-account search. For my personal account, though, I’m extremely reliant on Gmail’s web interface. I’ve used Mailplane in the past, and really loved it…with the exception of the inability to do cross-domain search. I use that daily.
On the mobile, there’s no option for cross-account searching. Mobile Mail.app gives me some native functionality and speed, but without cross-account searching, I’d much prefer to use Gmail’s mobile web app. HTML5 support in recent releases has made it faster, easier to use, and hands down one of the best mobile apps on the internet. I used Mobile Mail to connect to my Gmail accounts over IMAP because having multiple bookmarks was clunky no matter how I configured it, but I was always looking for something better.
In all cases I use IMAP because it keeps accounts in sync; changes made on the computer, the web, and the iPhone are all synchronized via IMAP.
I never used Push for my email because, well, I get a lot of it. I rely on Push for contact and calendar updates, but for email…if I haven’t checked my mail in 10 minutes, I can be sure that there’s something new in there.
Worse are unread counts. I’m compulsive about unread accounts. Mail, RSS feeds, Campfire, whatever it is…I hate having things unread. It’s a bad behavior, because I treat unread counts like to-dos, and in all of the scenarios where unread counts keep me on my toes, they are essentially to-do lists that OTHER people can put things on to. I’m already busy, I don’t need someone else to put more things on my to-do list.
The biggest loss in using Mobile Mail.app is tags, something that I do use pretty extensively. I’ve learned to get around it in Mail.app, which has better drag and drop support for moving things into folders that represent tags over IMAP. Mobile Mail.app was just clunky, and I resolved to not do that interaction on the go unless I had to.
I know I’m not describing everyone, but I am describing a lot of people. And as more corporations move their mail infrastructures away from Exchange and into Hosted Google Apps accounts, the group with this set of needs grows more and more.
A few weeks back, Dave Martorana (of MultiFirefox, Multiplex, and Two Guys on Beer fame) slung me a prototype of an app he’d been working on at IndyHall. It was called “MultiG”, and was basically an app that did fast account switching between Gmail and Google Apps Gmail accounts. It was rudimentary, but instantly useful for me. He quickly added an “unread” count to the accounts dashboard, but then did something I had never seen in an email client. He added a secondary badge that showed how many messages were actually new. I mean, how many of your unread messages weren’t there the last time you looked.
Think about that for a second. The anxiety of unread counts has finally found its Prozac. All I care about is how many messages are new! In casual conversation, I dubbed this feature “TrueNew”, something that I hope other developers build into their app notifications.
At this point, I was hooked. But Dave wasn’t done.
He’d also whipped up integration with the iPhone’s native address book. I haven’t gone through the process of moving my address book into Google, and again, I have multiple accounts so where would I sync my address book to? Not all of them.
Dave added a button to the chrome of the Gmail browser window in his app that let me pull up my iPhone address book and insert email addresses right into the “To:” field. Sneakily, if I turned on CC or BCC, the exact same feature gave me the choice of which field to put the address in to. Simple, sleek, lovely.
Since emails tend to include attachments and links, Dave also put in a handler that made sure that they opened without leaving the app, much like our favorite iPhone Twitter client, Tweetie.
This feature set changed the way I interacted with mail on my iPhone. It made my life better. It made one of the most painful parts of my day, dealing with email, less painful.
We realized that “MultiG” was a lousy name, and Johnny Bilotta (the other Guy on Beer) proposed “Mailroom”.
Sold.
He whipped up a sexy icon, and we were off to the races.
Dave got the app in the hands of a few other testers, worked out some kinks, processed some feedback, and with the hand of myself and co-conspirator Amy Hoy pushing him to “ship as early as possible”, got it into the App Store.
Initial feedback was mixed. People who were like me in terms of email use loved it. People who had different email workflows weren’t as convinced, and many people saw it simply as a “wrapper for Gmail”.
Technically they were right, but they were missing the progressive enhancements because they didn’t augment their workflow. The app wasn’t for everybody, and we knew that. We’d still struck a chord with a good number of our initial users, and got some great feature requests.
2 weeks later, Dave pushed out a significant release to Mailroom. We’d prioritized feedback against our desired feature set, and introduced some new ideas of our own. At the root of the new release was a settings screen.
Badge Icons were a huge part of our 1.0 release feedback. We’d been hesitant to include them by default because, without Push (which I’ll get to in a minute), the counts were largely inaccurate most of the time.
Since we wanted to encourage people to start using TrueNew, we made that the default badge icon if enabled, but gave the user the ability to turn on unread counts instead.
Another major improvement was both workflow and performance related. If you only had one account and used Mailroom, launching the app to the dashboard was wasteful. If you left Mailroom on a given account screen to go to another app, launching put you back at the dashboard again, which was undesirable. We gave users the opportunity to remember the last account used, meaning that as soon as they launched the app they were where they left off last. This immediately made my email experience more efficient.
And as a bonus, Dave gave the user the option to lock screen orientation. Not something I was particularly needy for, but a nice touch nonetheless.
And then there’s that last setting. Cache management. What’s that, you ask?
Well that brings us to the biggest quiet improvement to Mailroom 1.1. The app is now taking advantage of Gmail’s HTML5 offline storage. What does this mean?
It means that every time you visit an account, the entire interface is cached locally and a HTML5 database is created/updated with the email on your screen. Kill your connection (because ATT sucks, because you’re on an airplane, or because you’re in a meeting) and Mailroom is still useful. In fact, you can not only read messages, but you can reply to messages and even COMPOSE NEW MESSAGES without a data connection. As soon as you reconnect, your cached messages are sent while retrieving new mail.
He even made the multi-account dashboard smart, only allowing you to enter accounts that had offline caches from a previous visit.
Yesterday, all of these 1.1 features hit the iPhone App store, and already a large percentage of our users have upgraded. One of them left us a review in the app store that commended us not only on the app and how great its icon is, but on Dave’s responsiveness to feature requests. Big win for us, that’s exactly what we wanted.
We’ve already talked about feature roadmap for 1.2 and 1.3 releases, and it’s very much in the works. The plan is to continue with iterative releases, process feedback, and continue to grow the user base all at once.
Two “issues” continue to arise: the lack of Push badge updates, and the $2.99 price point of the app.
First, push isn’t as “simple” as some of our reviewers seem to think it is. Among the scaling concerns we have about people who move a lot of email. I ran some averages and my smallest inbox gets well over 24,000 emails a year. Those numbers aren’t staggering, but across the customer base we’re targeting, that becomes a LOT of notifications to deliver.
The real technical challenge is more complicated though. In order to accurately update badge icons over push, we’d need to store email addresses and passwords on a server somewhere, and that’s a HUGE security risk that we can’t figure out how to justify. I know I wouldn’t want that info out there, and I have to imagine that our users wouldn’t like it either.
So until we come up with a more elegant way to support push, Dave has built in an app-specific URL handler. Calling mailroom://username@domain.com from another iPhone app or even from a mobile web page launches Mailroom, and even jumps straight to the account if there’s one in mailroom that matches the email address in the URL. We’re hoping that other push services like Boxcar and Prowl can build in support for our app. We know it’s not the best solution, but given the infrastructure for Push provided by Apple, we’re pretty limited in what we can do. We don’t want to deliver a half-assed experience, so until we figure this out, Mailroom will not support push. If anyone has suggestions for how to overcome this hurdle, our ears are WIDE open, so please, sound off in the comments or via email.
And about that price point. Some customers seem to think that $2.99 is too much for an app that’s “just a webkit wrapper”. I won’t do more than touch on the fact that it’s not just a webkit wrapper for the right users and workflows since I’ve already explained here. But why $2.99? First, we’re targeting business users and we know it. They’re more comfortable spending more money on apps because in most cases, businesses equate cost with quality. But more importantly than that is the fact that this is, in most cases, a high-touch app.
99 cents for an app that you’re most likely going to touch at LEAST once an hour, if not several more times in a given day, feels undervalued. Like Tweetie, which I launch several times a day, I feel like I get an immense value for the $2.99 I spent on it.
Fact is, our first release might not have been worth $2.99 for everyone and you could say they got pegged with an “early adopter” tax. But since we’re not charging for the updates, and plan to roll them out often, we don’t think its really a tax at all. It just means that you will continually get more value from the app you already paid for.
We’re confident that future releases in our roadmap will continue to win people over the price point and even the “it’s just a webkit wrapper” theme. Mostly because, we’re listening. We hear what people like, don’t like, and how they are using the app. The more people feed back, the more they help to shape the future of Mailroom.
If you haven’t already, please consider heading to the App store and picking up a copy of Mailroom for your iPhone or iPod Touch. We’d love your feedback, and absolutely appreciate you supporting independent software development. You can also follow us on Twitter for app updates, or send us ideas and feedback there as well.
Find out details or sign up below. Save $75 by using the code DANGER.
CulturedCode is going to make a ton of money next week
And I’m glad.
Things is launching at next week at MacWorld, and my predection is that they are going to make a killing. I wanted to note a few reasons why, outside of the fact that it’s a really great app.
- The Cult: GTD, David Allen, and the rabid cult behind them are now well past phenominon and fast creeping into the task workflow of people outside of geeky industries. Building a good GTD app and launching it now is good, opportunistic timing. You can’t ride a wave too early or too late. You need to hit the crest just right. I think these guys did it.
- The long-ass public beta: I’ve been hearing about “Things” for what feels like forever. In fact, the public alpha was released just a touch over a year ago. For a relatively small, very well focused app with a talented design and development team, a year is a really long development cycle. But while the journey from alpha to RC1 was long, it read like an epic, as the application gained critical acclaim and positive reviews from many seeking a GTD app. All the while, providing feedback to make the final, saleable product totally rock. I’m pretty curious how exactly CulturedCode managed their feedback loop, what they did to prioritize feedback against their own roadmap.
- Dealing crack: ok, you’re going to need to stay with me here. You build an app that caters to a reasonably large (and growing) audience’s need. You involve them in the development cycle, giving them the software for free as thanks for being an active part of the feedback loop. The users become dependent on the software not just because it’s software they need, but because it feels like their own. When you take the product out of beta and put it for sale, your conversion rate is going to be excruciatingly high because they’re dependent, they are addicted. You’ve sold them crack, and while they could go to another dealer, many won’t. Some due to loyalty, but mostly, they’re hooked on your stuff and don’t remember how to function without it. It’s how I feel about things like the Web Developer toolbar and Firebug. Sure, I lived before they existed, but I’ve blocked out all of those awful memories. They could charge for those tools tomorrow and I’d pay without thinking, and I barely ever write code anymore.
- Charging for Paraphanalia: Again with the drug metaphors. Glad you’re still with me.Not having a good iPhone app for your productivity software would be a travesty, especially since the iPhone somehow lacks a to-do list natively (wtf?). CulturedCode COULD have given this software away for free. That would have hooked even more people, right? Maybe. But wait, they’re giving away their primary product for free too, right? Not really, in this case, “free” is temporary. So you’re addicted to a really great “free” app, and a really good companion app is only $10? Well sure, I’m in for that. Do you see what happened there?A “free” app turned into a $60 total sale. That’s smart. Charging for the iPhone app showed that they were serious, something that a lot of developers forget to do now and again. It’s important, because it’s really difficult to take a product seriously when it’s not well supported, and you’re crazy to think you’re going to support a product alone for its entire lifecycle without making any loot from it.I add the caveat alone because someone’s going to bash me in the comments saying that “open source software often has better support…” blah blah blah. I know it does. But rarely from the project’s originator. So I’m sticking to my guns here.Back to my point, adding money to the equation is a measure of commitment and seriousness from both sides of the equation: it says that the developer values their own time and work and plan to continue working on the application and it says that the customer isn’t just casually interested, but is invested the value this application provides them.
- Let’s not forget, it’s a great product: All of the marketing in the world can’t make a shitty product awesome. If your product is good, it sells itself. CulturedCode did a great job of everything from blogging about the product revisions, behaving like a human being (actually, a team of human beings) rather than a company on twitter (I bet they wish that co-tweet had been around, it’s perfect for their use). But most of all, they built a product that their users wanted to talk about, and gave them points of reference (blog, forum, twitter, full featured beta software) to do their buzz-bulding for them. They threw a really great cocktail party.
At the Eye of the Storm
Jason, Dave, and I had a conversation at the end of the day today at IndyHall (where I’d estimate nearly 1/3rd to 1/2 of our regulars utilize Things) about the price point. I’m a firm believer in setting a price and sticking to it, but I have to think that without all of the smart moves I listed above, that $50 price tag would scare quite a few people away.
CulturedCode COULD have run a more traditional development cycle, still come out with a decent app, and charged $25 for the desktop and $10 for the iPhone companion (maybe a $30 combo deal?), put some cash into traditional marketing, and it would have flown off the shelf and into the hands of every man, woman, and child who needed to get their shit together.
But they didn’t.
They built a great app, spent a year actively working with their customers-to-be, and are going to sell the daylights out of it at $50 a click.
Well done, CulturedCode. If you have any interest, I’d love to speak with you and write up a more formal case study about slow-marketing your application. I’m very impressed.
Find out details or sign up below. Save $75 by using the code DANGER.
