It’s always nice to be recognized. And since part of the purpose of this blog is to serve as a historical record of my professional life, figured I should post about it here before I lost the link to the sands of time 😉
Off late I have started using quite a few location based services like Foursquare, Foodspotting etc, and everyday more interesting apps crop up. However the current model for location based apps requires me to check into each app individually. The problem is when I am at someplace interesting enough to check in to, I am usually with people and I can only take so much time peering into my phone before coming across as rude to the rest of the group.
Compare this with how I interact with photos today. I take a pic and then can choose among any number of apps on your device that can do interesting things with it. Even better, I can manipulate the photos after the event I was taking the picture at.
I feel the whole model of checking-into a location has matured to a point where it can graduate from the app level to the platform level. I would much rather bring up some native location app and check-in to my phone. The check-in is an actual object, like pictures or music and it is now owned by me. It contains the location information as well as the time. Once checked in, I can “share” my checkin to any apps that can do something with it. So I can forward my checkin to Foursquare to inform all my friends I am there, to FoodSpotting to discover whats good to eat there and to any other app that may need that info.
This model has a number of advantages to it:
- I am building up a location history that is no longer trapped inside one app or service.
- I can choose to share my checkin with apps later (for example if my only motivation was to get some virtual points for being there, I can check into that service the next day)
- I can checkin to multiple services in poor connectivity locations by only needing to pull in map images etc once.
Of course there are certain challenges here:
- Some services like Foursquare may want to know immediately when you have checked in to present local offers etc. This could be done by the platform sending a system level event that these apps can listen to when a user checks in to a location.
- Different services have different location data, for example Foursquare has a lot of geo data but Foodspotting may have better data on restaurants so there will be the need for some standard model of annotating the location with other meta information while the user is locating himself on the map. For example, the map the user is presumably zooming in to can show pins from different services with different icons.
Hopefully platforms like Android and iOS add this capability as a core part of the OS pretty much like we use maps today. Till then, the idea of using more than one or two location services at any point is pretty difficult.
I am a chronic doodler, and have always struggled to keep my notebooks clear of doodles and seem more “information heavy”. So watching this video was quite an eye opener:
Another link from Time here goes deeper into a study that shows how doodling actually helps you pay attention!
If you really enjoy doodling, I strongly recommend Doodler’s Anonymous, pretty much the definitive blog on doodling. Their post on Netflix Envelope Doodles is just amazing and on my permanent list on links for when I need some creative inspiration.
Pity the doodle.com domain is owned by a web app that has nothing to do with doodling in the artistic sense (but still a fantastic app that I use quite often). Would love to see Quasimondo’s ScribberToo app there 🙂
This week’s design themed Android Alliance Philly meetup was a lot of fun. Here are my slides from my talk on Android UI design patterns:
Thanks everyone for coming 🙂
[Update] Other design resources:
Another month, another Todo list app tried and given up on. The latest candidate is The Hit List, a beautifully designed Mac application. However, it lacks any online component and as I move between different machines, the lack of being able to add/remove items from some web interface finally got to me. Pretty sad, since I really liked the interface.
I have now lost track of the number of Todo lists I have tried. I liked different ones for different reasons. For example:
- GMail tasks: is awesome because its right there within GMail where I go multiple times a day
- Remember the milk: I love the simple natural language way you can add tasks
- The Hit List: Really polished UI
- Epic Win: Completely useless as a todo list app but really fun to use 😉
- Teux Deux: Elegant design, iPhone app is a plus (well not anymore since I moved to Android)
While todo lists like the ones mentioned above are cited frequently, I feel enterprise project management and issue tracking solutions are little more than glorified todo lists are they? Working at Comcast. I have gone through quite a few of them, like Trac, RedMine or Rally.
So why isn’t there an OPML like exportable format for todo lists? I jump between todo list apps much more frequently than my feed readers and from what I read, so do most people.
Since most todo lists seem to always work with the same data an exportable/importable specification to define them would reduce the friction of trying out a particular tool a lot. Moreover, an agreed to format would also allow interoperability. For example, at work while we are all mandated to use the same “enterprise app” to manage the work, its conceivable that you could work with the same server while choosing different clients.
I imagine a spec like this to define todo lists:
This is of course completely not thought through completely, so I am sure there could be other items that would need to be represented, but hey, its a first stab.
For extra points if we could define an RSS-like spec for tasks that would be even better. That way clients could subscribe to tasks from services like mentioned above. If you are developing a better UI for task management, you could just build the UI part and leave the data management to some other service.
I have way more ideas than I have the capacity to execute.
That seems not an uncommon issue among my friends, and unlike that saying about ideas, I actually dont think everyone has ideas. Or rather, not everyone is passionate about ideas or seeing them through to some kind of product/feature anyway (people often mistake opinions for ideas). But there are definitely a lot of idea people out there. And in today’s hyper connected world, this has enabled a slew of services ranging from idea gathering platforms like Uservoice, Kindling to complete “idea to product” services like Quirky to emerge. [Update: Wall Street Journal has a fantastic article on Ideas that you must read, also my friend Karl Martino has just published a post with 3 other links on ideas]
One thing I have come to agree with is the thought that ideas are merely multipliers of execution, i.e. ideas are great and everything but what really counts is the execution. Occasionally, when someone shares something interesting and someone dismisses it saying “Oh I had that idea a while back”, I wince. Its that kind of thinking that often leads to people posting stuff like this, feeling cheated of success that should have been theirs because they had the idea first.
Execution is everything.
Or is it?Â Yesterday I read a rather awesome post by Jeff Atwood on the growth of his company (Stack Overflow) and his continued belief in what he calls “Boyd’s Law of Iteration” based on the findings of USAF Colonel John Boyd:
Boyd decided that the primary determinant to winning dogfights was not observing, orienting, planning, or acting better. The primary determinant to winning dogfights was observing, orienting, planning, and actingÂ faster. In other words, how quickly one could iterate.Speed of iteration, Boyd suggested, beats quality of iteration.
The same seems to be true of product development. Jeff references projects like Google’s Chrome and Android and how they are getting to be really successful because of their fast iteration cycles. The official Chromium blog recently published a post on the accelerated release schedules and further mention their three goals for the accelerated releases:
- Shorten the release cycle and still get great features in front of users when they are ready
- Make the schedule more predictable and easier to scope
- Reduce the pressure on engineering to â€œmakeâ€ a release
Over the last few years, I have released quite a few projects including:
- FlexAmp: An online mp3 player that plays audio from an online storage system like Box.net (now broken)
- DiggGraphr: A treemap visualizer for Digg stories (now broken)
- EspressoReader: A desktop client for Google Reader
A huge personal milestone for me was EspressoReader’s second feature release. I realized that of all my projects (not including open source libraries like OpenPyro of course), Espresso was the only project that ever had a second iteration that actually evolved the app (my other projects have had maybe one or two minor updates for bugfixes). The funny thing is, I have a lot of personal notes on features for v2 of all of Â them.
So here is why I think a lot of my projects never have a significant version 2:
- The developer itch is gone: I started a project because I was interested in a platform or an API and the part I was curious about is gone.
- The last 10% sucks: I realize that there are so many edge cases to consider. The app is very demoable but isnt at a point where anyone can actually use it for long without hitting a bug
- The damn codebase is a mess: To get to the part where the app proves the concept, I have taken shortcuts that have compounded on each other. So now there is a lot of work involved to get the app to a state where it has the same functionality as before but I don’t groan every time I open the project’s source.
- There is a shiny new toy to play with: These days its iOS and Android, both platforms I am interested in and spend enough time between 9-5 on to be able to take on a project involving em (well more iOS than Android as of now). Its really hard to stay focussed on a platform that is not the shiny new thing.
I hope as I mature as a programmer, I can curb my tendencies to jump off of projects for the above reasons. All I can tell you right now is that there is definitely at least a third version of EspressoReader coming out in the next few days :).
I am pretty excited to announce the first public release for EspressoReader is now on the Adobe AIR marketplace. Like I had mentioned in my last post, EspressoReader is a desktop client for Google Reader that I have been working with Alex for a while. While the application is pretty functional right now, there are a lot of cool features I have in my head that will make it truly a awesome experience.
There were a bunch of motivations that led me to work on this application:
- I was pretty bored of the uninspiring (though functional) UI of Google Reader.
- A lot of my feeds would contain duplicate content (say every time Facebook added a new feature, it would be reported by Mashable, Techcrunch, etc). So Espresso loads the feeds ahead of time in a local database and parses them to find duplicate content and shows them as related items in the related items sidebar (only if you are in the List view of the application though).
- Navigating to the feed I wanted to read using the Tree control on GoogleReader was fairly tedious. Espresso also does a good job navigating a through your feeds using “quick jump”. At any point when you are using the application, you can hit the spacebar and bring up a textfield that’ll let you jump to any feed or folder you have in your subscriptions.
- Sharing stories on Twitter was a chore in Google Reader. In Espresso, you can just hit the share on Twitter button and the twitter status field comes up immediately.
As with any “first look” release, this release is only about the core features and there are many things that still need to be added. For example:
- The splash screen that you see when you launch the application needs a lot of work. Friends’ Feed doesnt currently show the person who shared the item and the links open in your default browser. Going forward this will be better integrated into the application itself.
- Links right now open in your default browser. This will change and there will be an integrated web browser (with a setting to open links in your default web browser).
- Photos in Magazine view
- Offline access
- Adding/Managing Feeds and Subscriptions (right now you cannot add new feeds or move them to different folders)
etc etc. If you have any other ideas/suggestions, please leave a comment on this post.Â I am really looking for feedback on this release.
Here is a quick video of the application in action (reposted from the previous post):
If you are on Twitter, you can follow me or espressoReader for details on updates etc. I have also started a wiki to list the features/todos/help which is pretty bare right now but will hopefully grow as time progresses.
[Update: version 0.8 released as well with Twitter Profile “Guesses”: More here]
I am a big Google Reader fan, even if I often find myself overwhelmed by the number of feeds I have to catch up on every time I fire up the the web app. For the last few months I have been working on an app that would help me manage my subscriptions. With the help of Alex, a friend and a fantastic designer, I have been working on V2 of EspressoReader: a desktop client for Google Reader.
I had released an earlier version a while back but back then I had limited knowledge of the (undocumented) Google Reader API. The new version has been written from ground up and includes a lot of interesting features like:
- List view and Magazine view for feeds
- Quick “jump to feed” shortcuts
- Related feeds algorithm that scans your feeds for related content
- Sharing options with Twitter and Google Reader
Here is a quick video of the application in action:
I will post the latest build of the application on my blog soon, but if you are interested in this build @ or dm me on Twitter.
Stay tuned for an update coming soon 🙂
In case you haven’t heard already, this Wednesday (April 28th), the Philadelphia Adobe User Groups will be holding a joint event celebrating the release of the Flex 4 framework and Flash Builder 4 at the Wharton’s Jon M. Huntsman Hall,Â Room G65. We’ll have Terry Ryan, Flash Platform Evangelist for Adobe speaking at the occasion and there will be food and a bunch of giveaways. The event is jointly being organized by the Philadelphia Flex, Flash, ColdFusion, Photoshop and Illustrator User Groups so its a great opportunity to connect with other groups and group managers as well.
Hope to see you there!
Ooooh, I think this may actually be a good idea.
We know that Apple is trying to keep its developer base isolated from the rest of the mobile world. If you have to choose a platform between iPhone and Android, an indy developer will probably choose the iPhone right? Thats where the people are. This has nothing to do with the Flash Player, but everything to do with making the iPhone a hard ecosystem to leave for a user.
Now Adobe, imagine you releaseÂ an Objective C library that developers can use that will also cross compile to Flash Player bytecode that can run on Android, web etc. You already have done some work for compiling C/C++ to Flash Player bytecode in the Alchemy Project, and I am assuming you now have a bunch of of LLVM experts in your team. You will have to mandate that developers use only that library since others may not work with the cross compiler (there may be dependencies that are not ported). As an indy developer trying to get to the maximum audience I would use that library in a heartbeat. Now suddenly a lot of games are being automatically ported to the Android platform (with AIR). Except that those games appear on the Android immediately, rather than wait for the few weeks/months of sitting around waiting to be approved. The Android now suddenly looks like a better platform doesn’t it. Meanwhile this works nicely for you again. You need some IDE (maybe Flash CS5) to cross compile the Objective C to ActionScript bytecode so you have a market for a tool again. Get Google to help you by replacing the iAd system with one that uses Google ads, I am sure they’ll get behind that.
[update] This is not really a solution for people who dont know Objective C and dont want to learn it. But it does give iPhone developers more options, unties their dependence on that platform only and makes AIR on other devices a lot more viable.
Hopefully you like this idea, I’ll expect a check from you soon 😉