Arthur Chang

Pitch with a Question, Use Case, or Description?

Having a startup naturally lends you to situations where you're describing what product your company is building.  Whether pitching to friends, relatives, other startups, or investors, it's a pitch to potential customers in one form or another, and they're all different!  Some people are accustom to pitches and are able to switch into the mindset of understanding the concepts you're describing.  For others it's easier to give them a use case that applied to yourself, or possibly to them if you know enough about them.  And maybe you just have to feel them out and ask questions.

When people talk about pitching ideas, they start thinking of adjectives to describe how "amazing" or "simple" or "powerful" their product is.  Then they talk about the concepts and parts of the product that are one of those things, peppering it with those adjectives.  It's easy for someone to understand what your building, but it's unnatural for the average person to realize why it's so cool for them.  

Face it, nobody cares about something unless it benefits them.  At the end of the day, nobody is thinking about how cool a product is for a mass of people that's unrelated to them.

I've been experimenting with how to pitch FanPulse to people.  In the end, they always get it, but how excited they are varies tremendously.  Some people are excited because I've successfully persuaded them that they are the ideal user, and they can really see themselves using it.  Getting to that point is hard, and you can't rely on the person to get there themselves.  Just telling them about your product isn't going to give them enough to realize how they could use it.  Some people have the ability to take ideas and products and somehow assimilate it into their daily lives, but that takes a lot of work on their part.

What if you asked a question to start a pitch?  The question could be asking if they have a problem that your product can solve.  Let's take a quick example for FanPulse: Have you ever wanted to keep up with sports that you and your friends love, but never have the time?  This is a hit or miss for sure.  Let's talk about the misses.  The person has zero desire for sports, so the answer is absolutely no.  The person is a huge hardcore sports fan who plays fantasy and has a set of box scoreboards they visit on an hourly basis.  So no, they follow it fine.

The ideal answer is: "yeah I used to follow the Oakland Athletics, but just never had the time to keep up."  Then it's easy to tell them that FanPulse is perfect because it spoon feeds them information about the games.  It's also easy to tell them that they will also be able to talk to their friends (in real life) about sports in conversations that you're usually left out of.  But what if they're not ideal?  Well most of the time it's not going to be.

A good starting question could be super simple. "Like sports?"  Probably, if not, you'll just have to impress by explaining the cool "Machine Learning Algorithms in the cloud" you built to impress people.  Kidding!  If the person really doesn't like sports, I'd probably defer to a use case for yourself.  Then they might realize that, yeah, I could like sports too if it was this easy.  Here's my favorite: A lot of my friends are Cal Berkeley Bears fans because they went to Cal.  I didn't, so I don't really care about the teams, other than the fact that a lot of my friends talk about them.  I wanted something to help me follow their teams without needing to commit the amount of time they did.  (pause for a nod from investor) FanPulse tells me what games my friends are watching, and if it's interesting enough, I'll check-in to a game so I can get updates just for that game.  Tomorrow I can talk to them about everything.  FanPulse is my secret weapon.

I'm pretty sure people will understand my story, and see the possibilities of them being in similar situations, or at least give me the benefit of the doubt that this is totally happening to masses of people already.  The use case is probably just the tip of the iceberg, so if they are still interested tell them what the product is.  FanPulse gives you lists of games, showing which friends or general fans are following, and you can also follow by checking in.  Check-ins then give you game updates, friend activity updates, and ultimately rewards you for your own activity with virtual goods and real life monetary goods like game tickets.  So there, I just told you (and could have drawn on a napkin) the basic features we have, but you can now connect it with the problem we're solving.

So how do you pitch?  Pitch with a Question, use case, or just a general description?  How about all three?  I'd love to hear what you guys think, and please don't take any of my pitching above as the real deal, they were just quick examples I pulled out of my pocket.

PR for Startups

Dogpatch Labs - San Francisco held a fun meetup last night with the topic of PR for Startups.  The meeting was a fairly informal general Q&A session with prepared questions from Ryan Spoon and Mike Hirshland of Polaris Ventures, answered by Venture Beat's Anthony Ha and Techcrunch's Jason Kincaid.

My co-founder, Joe, makes a good point that the meeting did an awesome job of showing us that these journalists are real people.  Not just faceless robots who don't act like the rest of us.  In fact it was definitely good to see that they were truly trying to get the best stories and has the same frustrations as normal humans do.  Biggest take-away from the Q&A session was to treat them like real people.

Some other things:

Don't use buzzwords when you pitch through emails.  Buzzwords just makes your product even more ambiguous.

Talk about competitors as well to jumpstart your description.  Sometimes it's better just to use a starting place, and then describe your differences and how you're better.  It probably won't necessarily mean the competitor will be mentioned, just that the writer will understand you better and faster.

The pitch should be only a few sentences otherwise it's too complicated for the writers to wrap their heads around in the short amount of time they're able to read.  It might be nice to include a really short video to your product, though I'd suggest at least telling them it's only 1 minute long.

Timing is important! 48 hours before a launch is a good time to make first contact with a writer.  As soon as possible when you raise a substantial round of funding, and if you put out a feature that isn't just awesome for existing users, but something really cool for people who have never heard about your product.

Feature pitches should be strategic.  Don't try to get press for features that only make existing users excited.  If it's something that will really draw other people who have never used your product, then it's worth pitching.

There's a ton of other things you can do, but just talk to them like real people, and treat them nicely!  They're not out to get you, they're just doing their jobs.  Hopefully your product will speak for itself.

Here are a few photos from the event:

Week 12 through Now

I guess it was inevitable for me to begin to lag on some reoccurring task, such as blogging weekly about the early days of the startup life.  But it's a clear sign that everything is so incredibly dynamic, that structure and process is impossible and more often times more crippling than beneficial.  The old saying that "every day is a new day," starts to translate to, "every hour is a new hour."  Ideas and goals can change almost by the hour if not earlier.  Tasks to do can't be scheduled as confidently as before, and never can we schedule anything that's not totally independent of what happens in the next hour, a week later.  Because of this constantly shifting life, I had to put blogging aside for awhile.

The product finally seems a little matured and polished now, which is an awesome feeling!  We're left with bugs and new features that constantly improve what we have already.  There have been a few scary moments where we pivoted a good amount, and everything has turned out well.  One of our biggest drawbacks has basically been solving the problem of the app only being fun when you have a bunch of your friends in it with you.

As a cofounder, I naturally had tons of friends, and played with the iPhone app and even the web app (when it was in beta until a few days ago) while engaging with tons of friends.  What we didn't have enough experience with was the emptiness of the app when first joining.  There were enough cool features you get without friends, like game updates and what not, but the enjoyment with apps these days, and sports in general, is the social aspect.

Since we started focusing on those areas, we've created a lot of awesome solutions that have proven to be highly successful in making people enjoy the core features of the app, and to start inviting and making new friends throughout.  I won't get into the details of all of it, and these are just super high level problems a lot of startups have, but it's a good lesson to remember: put yourself, as a founder of a startup, in the position of a new user as often as you are in the position of a veteran user.  It's easy to get into the trap of becoming a power user, and making the app awesome for only those types of people.  Wakeup calls you get with feedback emails, google analytics, and user testing isn't going to help.  You have to make sure that you're building this app for yourself, at every layer of the application, to fully understand how to build and improve your product.

The last few weeks have been awesome for us.  We have started on our full fledged mobile web app, "web" being the key here, so that it's cross platform on all mobile devices that have a browser.  No more excuses for those with a BlackBerry, or a Palm Pre, or Android phones, it's gonna work across everything!  On top of that we released a desktop web app (meaning non-mobile) with all the bells and whistles and more!  With good design and a really good understanding of our product from constant usage of the iPhone app, the web version was almost a no brainer in terms of all the decisions put into how it was built and designed.  The flows and interaction feedback have all been built according to our own experiences with the app, and the tons of different types of feedback we've received.  It's not even considered a "first" rev of our web app, this seems more like a 6th or 7th rev because of all the stuff we've already done on the iPhone.

In a way, it might have been better to make the web app first, then to make a companion iPhone app.  The cross sections between users and friends who like sports and have an iPhone app is small.  Going with a web app, then mobile web, we could easily tell everyone to get it, and then later offer up a fun little native app.  Also not completely holding your entire company at the mercy of Apple's app store is a good thing.  Before the web app, Apple's (often strange) policies could have completely ripped us apart.  But of course, there were many many other reasons to go native on the iPhone first which did no harm in attempting.  In hindsight, going for a web app first probably would have been a smarter choice.

Working on the web app on top of the iPhone app has revealed a ton of different layers of what our product can become.  There's huge potential here, and it's getting even more exciting.  On top of organic and viral growth, we decided to do some fun "guerrilla" marketing outings.  So, we hired some models to go with us to the tip-offs for March Madness in San Jose to help promote the app.  The models did a great job at attracting all sorts of people (dudes), and getting the brand out there.  The girls we worked with were really savvy when it came to tech promotion, and they were able to help everyone understand the app, and most importantly, to download and use it.

The branding helped, as everyone would at least check out the crowd around a group of girls promoting something and wearing FanPulse t-shirts.  Later when we went bar hopping, people would come up to us and ask about it, saying: "we saw FanPulse earlier, what is it?"  Of course the translation is: "We saw some girls wearing these t-shirts, what is it all about?  can we see the girls again?"

I'm not saying this is going to make or break the product, but getting the hardcore fans in early, and then evangelizing to some degree is definitely worth it.  We'll see how things go on with March Madness, it's really giving us some awesome activity within the app.  Photos of the girls (and dudes going nuts):

Week Nine Ten Eleven

We've come a long way from the first days of FanPulse, starting from Joe and I building the foosball table.  Yes, the foosball table was the foundation of our entire company, setting the mood and proof of how fast and solid we could build something so that we could start playing with it ourselves.

I haven't blogged the last few weeks about our progress because it plainly drained me enough every day such that I had no motivation to just sit and blog, instead I sat and coded.  We have huge news, our iPhone application has launched to the public in the Apple App Store as of last Thursday.  See the blog post about it here.  That day was really exciting.  For the next couple days it was almost all building hype, which included spamming the crap out of our friends, borderline begging people to join us in watching the SuperBowl, and also presenting opportunities to sport bloggers to be featured as our news content provider for certain teams.

Building hype is important beyond anything you could possible do in a startup.  Not just in volume of hype, but the method of going about it.  At no time do you want to ever build the type of hype that creates expectations for exceeding your ability, but that doesn't mean even the simplest of applications can't have a lot of excitement surrounding it.  Play off of the fundamentals of your app, what already works and works great.  Talk about what these simple actions can do for the users.  Make users feel like they will become even more awesome after engaging in the 2 or 3 actions of your product.  Most importantly, don't promise anything that doesn't exist or hasn't been built yet.  Build hype about the present, be proud about what you have now.  The emphasis should be all about what's going on with your product today, and how it's currently making people's lives that much better.  Never make excuses for things your app might lack, or needs improvement on.  Make it sound like we purposely made everything the way it is (which should be true anyway).  Give people confidence in the product without making it sound like a scam.

It's huge to be confident in your own product.  That alone will increase the quality in the eyes of users.  If you're somewhat timid about making a fool of yourself, then that means you're truly not proud of the product and that's a bad sign.  If you're not proud, then you shouldn't have even released something.  Startups all understand that first revs, and every revision after is nowhere near the final goal of taking over the world, but knowing that goes a long way.  You see the qualities of what you have now, and it really shows when you pitch the idea to customers, investors, and beyond.

Avoiding criticism by making excuses is a huge turnoff.  Take criticism as suggestion and a learning experience, don't try to guess what people might hate or not like.  If you're stern enough, people will start seeing things your way, and the most passionate and well thought out suggestions will come up.  And of course, you'll get a bunch of random criticism that all stems from people trying to use your product in a different way than designed.  This probably means the messaging for what your app is really about was not clear enough.  There are exceptions where people are just looking for yet another hardcore "scoreboard" app for example, which we aren't.  If you read even a single paragraph of text, you'll understand this, but some will not and miss the point completely.  Hey, that's totally fine, but there's always room for improvement to make even the laziest users understand what's happening.  Once that's good, you can hook anybody.

Every release and big event for your product is a huge learning opportunity.  Build like a madman, hype it up like no other, piss people off, make people scream with joy, listen and learn, then do it all over again.

We were lucky in many ways, biggest being the SuperBowl event.  We saw a huge number of people check-in and shout about the game.  Once your friends are all on the app, it's actually really awesome while the game is going on.  The need for more cross platform solutions became even more apparent as a lot of our friends were sitting around not being able to join in.  We're pushing forward on our desktop and mobile web version of the application immediately.  We have a shell page for games already in the works: http://fanpul.se/games/133633  This will be good news for non-iPhone users, and people who just like playing with things on their laptops and desktop computers as well.  We'll get everyone's friends on this soon!

Time to get back to work!  More updates soon.

Week Eight

Today was an important day in the history of FanPulse!  We have officially submitted our product to the Apple App Store.  It's pretty amazing how much has been developed in such a short amount of time, much attributed to the awesome team we have.  Above is a photo I took of Joe and Vish as we prepare for the app submission on Saturday.

It's a good feeling to have to hit your deadlines, however aggressive.  Sometimes that extra pressure helps and makes everything just a bit more rewarding.  What this doesn't mean is that we're all taking vacation, it's quite the opposite.  We're diving head first into the next round of features and improvements we have been planning all along.

The difference between an iPhone app submission and a web app submission is that web submissions are up to you, and you can do them as many times as you want and as frequently as you want.  With the Apple App Store, you're at the mercy of their process.  What we released was a great minimum viable product, but there's still plenty of awesomeness to build.

For all the new, casual, and expert sports fans out there, this is just a taste of what's to becoming the coolest thing you'll ever see =)  I'll be posting on the FanPulse official blog (http://fanpulse.posterous.com) soon with details, and once we hit the app stores you'll see plenty of updates and buzz.

You should follow us on Twitter for the latest updates here.

What startups are looking for in services they use

Are you an entrepreneur or a company that wants to make some success in providing some service for startups?  Get started by understanding what startups need.

Startups want to concentrate on their core features, any paperwork or supporting services they have to deal with, build themselves, and maintain is incredibly gross to anyone.  This is a huge problem for a lot of startups: minimizing overhead busy work.  Why would a company have to go through the mundane and standard processes of accounting, legal paperwork, and even technical features that are common everywhere?  Either it be a technical feature that supports the core product or a completely unrelated element of maintaining a startup company, it needs to be something that can run in cruise control.

Be a company that creates a service that solves the problem of abstracting perviously unavoidable tasks by basically creating the notion of: "set and forget."  The way I measure the value of a service provided for startups is how little people think about the service.  If things just work, and frees up time for core product development, then that is a good service.

A prime example is something like Superfeedr.  Julien of Superfeedr came to Dogpatch Labs to meetup with me, walked me through a lot of features I didn't understand, and really took his time to understand my problem.  He assured me his service would be the answer.  It took me a few days to setup, and months later, I haven't had to think about Superfeedr ever again.  It just works.  It's a feature that works so well I have had to dedicate no time into maintaining or tweaking it.  Time and peace of mind is the greatest gift any company could give me.

It's a good sign when people ask me how well the product is working, and have a lot of questions on how I'm solving problems of my supporting features, and I have no clue.  All I do know is that it works amazingly well, exceeded expectations, and never caused me to need to go into details of understanding why it works.

I'm also not advocating not doing your research and keeping an eye out for updates, better solutions, and so on, but there are plenty of times when it's of more value to be able to depend on a service that works well, might not be exactly the newest and cutting edge, but frees you up to really develop the aspects of your product that will get you users, get you rich.  There's always time later to optimize, and if you chose the right products to go with, those guys are going to optimize for you.

So that brings me to another point, gaining the trust of startup companies to just set and forget.  How do you portray that your service is going to be dependable to us?  Ideally in the long run, the product is going to be tried by many companies and have a really good reputation.  I have no problem seeing the all star products all currently using and advocating the use of some product and just committing to it. I trust everyone else did their research and have had good experience.  But getting to that point is difficult.

The factors that are important to getting to the point of being trustworthy is to be human.  Put a face and a team behi nd the product.  Be completely transparent so we know that you're not hiding your problems or success.  Be honest, you are making money too, and we want to know how and why.  Don't try to seem like a completely altruistic group of people, because that just seems way too suspicious.  I don't have any problem with a company making money off of me, as long as I'm getting tons of value and the prices are reasonable enough for me to continue on with business.

The initial partnerships or customers you have are really important.  Choose companies that are popular, blog and talk a lot about cool supporting companies around them.  The best I've seen go out in person to meetup, chat, and talk about their product.  Personalized service and real face to face assurance really helps validate any product.  It's hard to do, but worthwhile if you're talking to people that are heavily influential.

And when you are answering questions, don't position yourself as someone who knows more about the product and the features than the company you're trying to persuade to use your product.  Don't be stubborn or egotistic.  Listen to their feedback, their needs, and give in once in awhile.  Let them know you've definitely been aware of any issues or features they want but are not yet built, and acknowledge that the fact that they are giving you the feedback substantiates the priority of those products.  Constant and dynamic evolution of products are a good sign that it won't be left in the dust in today's pace of technological advancements.  Also making any startup feel like they have played a hand as an early adopter in helping shape the cool supporting product will help further the startup's advocation and evangelization of your product.  Asking for advice and feedback is one of the most valuable ways to keep networked with a lot of startups.

I have no doubt the majority of the companies out there have great products for startup companies, but the steps to actually getting into the hands of these startups as a viable product really hinges on the basic concepts of making life easier and enforcing constant trust is incredibly important.

Below is my plug for the companies that have made FanPulse progress so quick and has helped maintain such high quality throughout our development process.  If I missed you, that's probably a good sign, but let me know anyway and I'll add you to the list:

• Superfeedr - Pushes feeds to our webhooks.  No need to manage feed pulling processes ever.
• Heroku - Keeps our backend up and running all the time.  Provides awesome addon features that just work and need no monitoring on our part.  Also allows us to scale up in an instant, deploy new code, and more.
• Evri - Deals with our initial sports related Natural Language Processing.  Works all the time, it's awesome.
• Chatterous - Helps the founders communicate easily, even maintaining history when we need to go back.
• Github - Repository to store code, place to find and track plugins and addons to help development, provides a pretty slick bug tracker as well that we don't have to maintain.
• Amazon AWS (s3, ec2) - Helps us scale, do backups, and more, with little worry or effort.

(first photo taken last week on a walk with my family through Lands End in San Francisco, CA)

Week Six

Here's week six in my series of documenting the early stages of my new startup.  The purpose is to document our progress, our maturity, and what we learn and experience every week.

This past week has really shown me a few key things.  

Lots of startups are trying to launch right around Christmas, either to tag onto the shopping spree of the economy, or to get things finished so they can go relax for the holidays.  There's quite a buzz in the startup community about now, and you learn a lot from them.  There's also a high level of stress, especially the balance between work and holiday festivities, which include shopping, family and friend events, traveling, and more.  Best thing to do?  Stay out of it.  Depending on Christmas for your app to launch successfully shouldn't be your strategy, though I won't deny the boost it could give.  Either way, the ultimate success of your product won't hinge on it being ready for Christmas, if it does, you have other problems to worry about.  Other stresses include the Apple App Store closing down to any changes or submissions you might have during and around the Christmas day, long lines to get approved, and other elements of your product that are totally out of your control.

Another cool characteristic about this time of the year is that you're more likely to be around friends and family.  Holidays are a great time to practice the elevator pitch.  I've learned a lot about my product by talking to a lot of people, strangers and friends alike, that I probably couldn't have in the same amount of time with my co-founders or buried in code.  I left my echo chambers last weekend to go on a photoshoot with a seriously eclectic group of people.  There were new faces, familiar faces, and old faces at the shoot.  The photo posted above is from the event at the Maritime Museum in San Francisco.  I met a few developers in enterprises, a few from Google, a few from startups, and then also a bunch of other people in various trades and fields.  All of which had at least some interest in sports.  If not before we talked, definitely after =)

At the event, I was able to take a breather and walk at least 7 - 8 miles, enjoying the outdoors and the holiday decorations.  I also talked to a lot of different people, about the new company, about my new product, and about what they thought about it.  Sure I wasn't the only one talking the whole time, but I did get a lot of reactions and feedback.  By the end of the night, my pitch had matured dramatically from when the day started.

I am a developer most of the day, coding, but that doesn't mean that's all I need to concentrate on.  Founder status requires the responsibility of keeping your head above the clouds, out of the echo chamber, and putting on many hats.  Gathering data from feedback and analytics through the product is one thing, but also just trying to describe and basically convince people that your product is awesome gives you an idea of what people want before even seeing the product.  In essence, I was trying to sell vapor.  I get a little credibility for the vapor since I'm actually building it.  This weird "Matrix" type stuff I do on the backend seems to add just enough mystery for people to give me a little more cred than I would have otherwise =)

What I've done in this exercise is further gain another set of feedback from a totally different group.  I've also further improved the pitch.  I've substantiated more of the product's focus, and have more ideas on how to market the main features.  Sure it's not the final or only set of data go off of, but getting out and doing something completely different with a totally different group of people has definitely helped me as an individual become better in experience and knowledge to continue development of the product.  It also helped me step back a bit in my thoughts of my product, to reorganize what I have been doing for a few weeks, and describing it in it's most primitive of forms.  It really helps to be able to get out of the huge hole you've dug in your product, so you can remind yourself what fresh minds really think about a potential product of yours.

This further substantiates my belief that being a successful entrepreneur and developer is strongly aided by your ability to take part in other activities outside of your daily work.  I'm not saying go out to random venues to try to push your products, nor take time away from development or from the product in order to try to gain more feedback.  But go out and enjoy the world from a different perspective completely, keep your own self achievements a little more diverse, and you'll be amazed at how people think outside of the world's startup bubble.

Practicing your pitch also gets you organized, fresh, and thinking.  It keeps you from putting yourself into dead ends, or too far down the wrong road.

Also partaking in some holiday fun will help you rejuvinate some of that spirit and excitement that is constantly being sucked away by memory leak issues, internet explorer compatibility issues, and dealing with battling third party services (apple, facebook, etc) that you depend on.

Happy holidays everyone!

Week Five

Week five has been really exciting, and here is a little recap of it as part of my series of documenting the early stages of my new startup.  The purpose is to document our progress, our maturity, and what we learn and experience every week.

It's been a pretty exciting week.  Along with our great beta testers, being part of the target audience really helps as we can visualize and understand the app with first hand experience.  I couldn't imagine building something without having any interest in using it when it was done.  Building something that you will eagerly use is as exciting as it is motivating.

Week five was awesome, everything we did had a substantiated direction.  Instead of waiting around and trying to justify what we've built, we've proven a few theories, and totally eliminated others.  All the polishing we did made the app better, and what makes the app better?  By improving that core feature / functionality that everyone understands and uses.  We didn't spend time working on a page that only 2% of our users saw, and nobody really cared for.  We didn't spend any time adding in features that had nothing to do with our core functionality.  Everything we did helped people do what they naturally came to the app to do.

One big question we talk a lot about is, what's the pitch?  One thing to realize is that if your product doesn't dictate a clear enough pitch, it's definitely not focused or clear enough itself.  If we were making a machine that materializes a hamburger, and that's all it did, our pitch would be quite clear: "Our product makes hamburgers out of thin air."  I wish that's what we were making, but the reality is, few things are that simple to start out with.  It could have started with an idea to make food from air, an entire meal, multiple meals, for an arbitrary amount of people, possibly creating liquids to drink too, and with kosher and vegetarian modes, and what have you.  All of that is what a lot of different people want, but why promise so much when you could simplify to start with just making a hamburger and doing that really well to prove what you're capable of.

Once everyone knows exactly that one core feature that's where the excitement starts.  You no longer have as many lingering questions, nor too many tasks to tackle.  You don't have to hire tons of people to take care of each category of what your product has, but instead the core team that you like a lot working on the same core elements.  Simplifying will also help you release early and often, without ever needing to explain exactly what all the new things will help you do.  You'll know that you're going to get a better hamburger, and because of that you're excited right away.  You don't need to read into the bulleted list of features to know that.

Simplifying is the best decision to make, but it can also be the hardest one because you're letting go of all these features you were really excited about.  The best way to think about it is that nobody else is thinking as much into it as you, you're down a path way further in maturity than your product is, and that each of these features probably has a place and time in your product, but that time is later.  Wait until the audience understands and loves your core features, and then be the good guy who gives these people all the little features that they start to need.  The demand is what wil l keep your product alive after launch, the demand is what is going to help investors decide to invest, and the demand will show you the possibilities of generating revenue.  Launch with something that is awesome, just one thing.  You'll be surprised!

Anyway, the photo at the top is a picture of one of the natural bridges near Davenport, California.  I went down there a few times that day, trying to find the perfect lighting and weather.  It was raining pretty bad, and I was hoping for some breaking fluffy clouds, but settled for a dark semi-long exposure to capture a minimal look on these cool structures.  More on my Flickr stream: http://flic.kr/photos/kinetic

Week Four

Wow, I've almost lost count of how many weeks it has been since we started building our app (photo unrelated... mostly).  It literally started from scratch 4 weeks ago, and tomorrow we are already ready for our second beta release.  This isn't a pure web app, mind you, it's an iPhone app.  We got backend, frontend, api's, stat servers, natural language processing processes, and more, all playing nicely in 3 weeks, and now 4 weeks ready for another release.  On top of all of that, we have all the nitty gritty business details: seed funding, design work, branding work, marketing strategies, PR relationship building, shmoozing, twittering, and blogging.  It all really gets complicated, and it's amazing how we're getting everything in line and organized.

This week was dedicated to improving our first release, w hich I'd like to call our alpha.  After using the app ourselves along with 20 or so beta testers, we've really gotten to know how our idea works in real life.  An idea and a finished product are basically two completely different things.  What you think your product will be, is actually not how it will ever feel once materialized.  Focuses shift, things are stripped out, and the core features are redefined and polished.  Every release is going to throw curveballs at you, you just have to be ready for it.  All the features and ideas you thought were table stakes might just be superfluous things that really don't make your app cool.

With FanPulse, we've found that, sure, there's about a hundred different things people would love in the app, but does that make them more likely to open up the app again?  Nope.  What do they like the most, what do they use the app for?  That's what we need to focus on.  If there's an outrageous amount of demand for a feature that's outside the scope of our core, even more so than what the awesome feature the app is centered around, maybe it's time to look at another product that has been unearthed by your previous idea.  Yes that could happen, but don't force it.

Tomorrow we're releasing a set of features that is a continuation of our efforts to polish and make our core functionality work even better.  I still regard the next release as an alpha, as it's still testing out our earliest ideas.  I'm not against saying that it's not perfect or ready for the public yet, because it will be soon, and releasing small and often will pay off big time.

If you're not in our releases yet, and want to get in on this next beta, send an email to beta@wethefan.com with your name and email.  If you have an iPhone and know how to get your UDID, send that too!  We'll get you in for tomorrow.

And if you're all wondering what the heck the picture is above, it is of a Porcelain Crab.  The Neopetrolisthes ohshimai is not actually a true crab, but a squat lobster evolved into what is more or less a crab looking thing.  I think this evolution is called carcinisation.  Basically shows how crabs might have evolved from lobsters due to environmental factors (hiding under rocks for example).

Anyways, these guys are cool!  They use their claws to fend off predators or in my case a few harmless snails and fish, but use what's called setae to catch food.  Setae are basically a pair of arms that stretch out from underneath them that have "nets" in them.  They catch particles (planktonic food) and shove them into their mouths:

I currently have a mated pair in my tank, they sort of just hang out together and grab stuff out of the water column.  I doubt I'd be able to keep any of their offspring successfully, but it's fun having them as a pair nevertheless.

The Importance of Good Admin Pages

A good administration dashboard is key.  The whole reason behind an admin panel is to allow for human heuristic fine tuning of an app.  We need these either constantly or often, in order to maintain some aspect that just cannot be solved with computer magic (though many will argue that there is always a way, but the tradeoffs in some cases are not worth it).  Because of this, an aesthetically beautiful and equally easy to use admin interface is as important, if not more, than a user facing interface.  For computers, you want them to crank through really gross algorithms that would otherwise be impossible to maintain in your own brain.  For administrators, you want to make the experience of administering a site as pleasant and easy as humanly possible.

The big reason why people neglect and cut corners on admin facing pages is because "nobody ever sees it except us."  But isn't that the most important thing?  If you as employees only see the shittiest parts of your app all the time, or subject poor interns and new hires to this awful task, it just shows how little attention to detail you give to making your app hum like a well oiled engine.  When you develop any part of your code, always ask yourself if this is quality you are proud of, internal and external to your own company.  At some point horrible admin panels will just pile up, and there's no turning back.

If you start with a slick looking admin panel that works great and is easy to maintain when things change, then you will always have an awesomely tuned app with consistently great admin controls.  If you start with quite a grotesque arrangement of links and badly styled form fields, anything slicker than that just makes what you've built already look even uglier.  It's a bad snowball to be in.

It's easy to choose admin pages to cut corners on, because there's never an imminent need for them.  The time it saves is clearly good initially, but leads to plenty of cursing and swearing later on.  So what's the solution?  In some frameworks, such as Ruby on Rails, there are nice little things like Active Scaffold.  Unfortunately DHH and the rails maintainers aren't the world's best designers.  The usability, looks, and consistency are all pretty bad using the built in utilities.  At FanPulse, our current admin looks good, works great, is easy to maintain, and is even easier to expand on.  What we did is we used the somewhat popular web app theme utility for our rails based app called, "web-app-theme" by Pilu.  I guess it's not that clever of a name, but it works like it reads.

The tool is actually a ruby script that can be used with the script/generate command.  It basically sweetens up an existing active scaffold, or any model based controller.  It even creates all the files from scratch to you.  It comes prepackaged with a dozen nice themes that are super clean and easy to use.  It took me less than a day to create an expansive admin panel that can help us keep track of, modify, and add new teams, players, leagues, divisions, conferences, sports, beta users... you name it!  This will save us hundreds and hundreds of hours of work, and make administering the app just a tad less tedious.  Of course, if your app requires tons of administrative work constantly, there's some other decision that has gone wrong.  In our case, we need to do some fine tuning once to make sure all our data is totally perfect.  It's also great for adding new beta users and all that jazz.

The web-app-theme generator is geared towards being a good launch point for an entire web app, not just an admin panel.  I'm not that excited to take these designs and showing them to the world, but they look and feel great for administrative purposes.  So I've tapped into using it exclusively in an admin only side of our app.

They key to making it an admin only app, is to use elegant Rails Namespaces, which came about in the rails Changeset 6594.  This allows you to group controllers for specific models inside a namespace.  I chose the namespace called "admin".  This effectively gave me the ability to create a subdirectory in the app/controllers directory called "admin".  Then under there were all my individual controllers for individual models.  My routes.rb looked as so:

 

  map.namespace :admin do |admin|

    # The below resource mapping directs /admin/teams/* to Admin::TeamsController (app/controllers/admin/teams_controller.rb)

    admin.resources :teams

    admin.resources :players

    admin.resources :users

  end

 

The above snippet shows how I have a model controller for each model.  By doing this, you can maintain a super restful way to setup your controllers, using the usual index, show, edit, update, new, create, destroy actions with their respective get, put, and delete request methods.  Also maintains a great way to use named routes with: admin_teams_path to goto the index action of the teams controller under the admin namespace.  Another example is new_admin_team_path for going to the new controller.  One thing to note is for other mentions of controllers outside of this admin namespace, use a prepended slash to specify no namespace.  For example:

redirect_to :controller => '/session', :action => 'new'

The above takes you out of the admin namespace because of the prepended slash in front of session.  Otherwise it will try to hit you with admin/session controller, which probably doesn't exist.

Once you've installed the web-app-theme generator, and setup your routes, you can then create initial admin layout and styles:

$ ruby script/generate themed admin --theme="drastic-dark"

The generator is called "themed" and the parameter "admin" is what we want the layout to be named, in this case it will automatically create an "admin.html.erb" layout file for you.  The option "--theme" is where you designate what theme style you want to go with.  Pick from here: http://pilu.github.com/web-app-theme

Once that's done, create a view for your first model controller (controller can be created after):

$ ruby script/generate themed admin/teams --layout=admin --with_will_paginate

The above will generate all the views for you under app/views/admin/teams using the layout we generated before as well as scaffolding the views up with will_paginate automatically.  Good if you have more than like 50 entries.  Then create your controller using the usual ActiveScaffold, but give it a namespace as well as a "global" layout:

class Admin::TeamsController < ApplicationController

layout 'admin'

...

The controller should be created inside the app/controllers/admin directory.  Given your routes were setup with admin.resources :teams, it should all be setup.  Oh and one last thing, if you used the will_paginate option, make sure you change the controller finds to paginate.  And that's it!  Do the same for all the other models you want to administer.  If you want to do one offs from models, it's easy to just use the usual template to put whatever you want in there.  Takes minutes, looks consistent, and is much nicer to use and expand on.

Make your employees happy in your startup, make the interns feel like they are not doing really sad work in, but actually being part of a really polished startup company.  Having a solid admin in your app is a huge indication of how well you plan everything you work on, including planning, researching options, and finding the most elegant and robust solution available.  If you can learn to use these tools quickly, you will go far in the rest of your development, user facing or not.

NOTE: I didn't do any editing of this blog post, just wrote what was in my head (as I usually do), so please excuse my crap grammatical errors and horrible organization of it all.  I'm not here to publish a book, just write my thoughts down.