Nowadays, people are overwhelmed with information. This signal vs noise problem keeps showing up everywhere.

In web design, preferences settings is consider a bad thing to have. Good designers make those decisions for their users.

“Innovation is not about saying yes to everything. It’s about saying NO to all but the most crucial features.” – Steve Jobs

In consumer products, companies with fewer product types tend to do better. Consider GM vs BMW and Honda. More choices tend to confuse consumers. Another example is Mac vs PC.

In dating, because of the existence of online dating websites, people tend to become restless. Why settle when there are so many options out there to choose from?

A few years old, you have Reddit vs Digg. Reddit used to be my favorite website. The quality of stories used to be better with fewer categories. Now, I read hacker news. How long would it be before hacker news become like Reddit? Consider another example: Twitter usage. You can tell when someone is using Twitter as a marketing tool when he is following more than 200 people. Unless you have nothing to do, and reading tweets was your full time job, there is no way anyone could handle all that information overload. If you are following more than 200 people, you simply don’t read your Twitter tweets. I know it because I don’t.

More is less. On the other hand, less is more. If I learned three words from more than one year of working on my startup TrAvid, this is it. Hence, the title of this blog.

** Support **

- Feel The Pain
Tear down the walls between support and development
listening to customers is the best way to get in tune with your product’s strengths and weaknesses.
Don’t outsource customer support to a call center or third party.
Get the developer to answer support emails.

- Zero Training
Use inline help and FAQs so your product doesn’t require a manual or training
Use tooltip

- Answer Quick
Quick turnaround time on support queries should be a top priority

- Tough Love
Be willing to say no to your customers
Be prepare to say no to feature requests

- In Fine Forum
Use forums or chat to let customers help each other

- Publicize Your Screwups
Get bad news out there and out of the way
Deliver bad news right away. Deliver the good news slowly to keep the good vibes.

** Post-Launch **

- One Month Tuneup
Issue a major update 30 days after launch
This will keep you focus on the core feature set at launch time
Generate the 2nd wave of buzz

- Keep the Posts Coming
Show your product is alive by keeping an ongoing product development blog post-launch
Keep a product update blog
Things to include:
Faqs
How-tos
Tips & tricks
New features, updates, & fixes
Buzz/press

- Better, Not Beta
Don’t use “beta” as a scapegoat
private beta is fine, public beta is bullshit

- All Bugs Are Not Created Equal
Prioritize your bugs (and even ignore some of them)

- Ride Out the Storm
Wait until knee-jerk reactions to changes die down before taking action
wait for 24-48 hours before responding to something negative

- Keep Up With the Joneses
Subscribe to news feeds about your competitors

- Beware the Bloat Monster
More mature doesn’t have to mean more complicated
resist the urge to add features
keep things simple

- Go With The Flow
Be open to new paths and changes in direction
Example: Flickr which started off as an online game

** Conclusion **

Start Your Engines
- Execution
Success is all about great execution in:
- web design
- good promotion
- good code
Constantly seek out your weak links and focus on them until they’re up to par.
- People
- More Than Just Software
Apply the principles to other areas in life

** Promotion **

- Hollywood Launch
Go from teaser to preview to launch
Teaser
drop hints on blogs
stay vague
boost the ego of a selective few to be the beta testers
put up a email collecting box
Preview
A few weeks ahead of launch, start previewing features
show screen shots
highlight features
tell people about the ideas and principles behind the app
collect emails
Launch
Send emails
post about progress: how many people have signed up
Keep posting about updates/tweaks
build the momentum

- A Powerful Promo Site
Build an ace promotional site that introduces people to your product
Include the following:
Overview: Explain your app and its benefits.
Tour: Guide people through various features.
Screen captures and videos: Show people what the app actually looks like and how to use it.
Manifesto: Explain the philosophy and ideas behind it.
Case Studies: Provide real life examples that show what’s possible.
Buzz:Testimonial quotes from customers, reviews, press, etc.
Forum: Offer a place for members of the community to help one another.
Pricing & Sign-up: Get people into your app as quickly as possible.
Weblog: Blogs keep your site fresh with news, tips, etc.

- Ride the Blog Wave
Blogging can be more effective than advertising (and it’s a hell of a lot cheaper)
Create a blog that’s helpful. Not just about the company.

- Solicit Early
Get advance buzz and signups going ASAP
Get some sort of site up and start collecting emails as soon as possible

- Promote Through Education
Share your knowledge with the world
You can give something back to the community that supports you and score some nice promotional exposure at the same time.
Education gives rises to healthy marketing, build up evangelists
Teaching Leads to Passion

- Feature Food**
They’re hungry for it so serve it up
Talk about the new features on blogs
Get people excited

- Track Your Logs**
Study your logs to track buzz
figure out where the buzz is coming from
Go to those blogs or forums, contact the people who praises you
Collect positive praise and create a “buzz” page at your site.

Inline Upsell
Promote upgrade opportunities inside the app
don’t forget to call out upgrade opportuni- ties from within the product.

Name Hook
Give your app a name that’s easy to remember

** Pricing and Signup **

- Free Samples
Noisy world. In order to get people to notice you amid the din, give something away for free.

- Easy On, Easy Off
Make signup and cancellation a painless process

- Silly Rabbit, Tricks are for Kids
Avoid long-term contracts, sign-up fees, etc.

- A Softer Bullet
Soften the blow of bad news with advance notice and grandfather clauses
Need to deliver bad news like a price increase? Give advanced notice.

** Words **
- There’s Nothing Functional about a Functional Spec
Don’t write a functional specifications document
Functional specs are fantasies

Functional specs are about appeasement
make everyone feel involved
Functional specs only lead to an illusion of agreement
people interpret words differently
Functional specs force you to make the most important decisions when you have the least information
Functional specs lead to feature overload
easy to add bullet points
Functional specs don’t let you evolve, change,and reassess
Specs don’t deal with the reality that once you start building something, everything changes.

Write a one page story about what the app needs to do.
Follow the process
paper sketch
html
code
Stay flexible

- Don’t Do Dead Documents
Eliminate unnecessary paperwork
Build, don’t write.
Documents that live separately from your application are worthless.

- Tell Me a Quick Story
Write stories, not details

- Use Real Words
Insert actual text instead of lorem ipsum
You need real copy to know
how long certain fields should be
how tables will expand or contract
what your app truly looks like
- Personify Your Product
What is your product’s personality type?
Think of your product as a person. What type of person do you want it to be?

** Priorities **

- What’s the Big Idea?
Explicitly define the one-point vision for your app
Mantra

- Ignore Details Early On
Working in iterations from large to small.

- It’s a Problem When It’s a Problem
Make decisions just in time, when you have access to the real information you need.
examples: scalability, features, servers

- Hire the Right Customers
Find the core market for your application and focus solely on them
If you try to please everyone, you won’t please anyone
Know who your app is really intended for and focus on pleasing them.
Polarize your customers

- Scale Later
You don’t have a scaling problem yet
Create a great app and then worry about what to do once it’s wildly successful.

- Make Opinionated Software
Your app should take sides

** Feature Selection **

- Half, Not Half-Assed
Build half a product, not a half-ass product
build half a product that kicks ass
Stick to what’s truly essential.
Take whatever you think your product should be and cut it in half.
Minimal Viable Product
Start off with a lean, smart app and let it gain traction.

- It Just Doesn’t Matter
Essentials only
Answer to customer support questions: “It Just Doesn’t Matter”
Leave out the nice-to have and not important features

- Start With No
Make features work hard to be implemented
Each time you say yes to a feature, you’re adopting a child. (e.g. design, implementation, testing, etc.)
The secret to building half a product instead of a half-ass product is saying no
Don’t be a yes-man
Feature request => No.
If keep hearing about it, implement.
“Innovation is not about saying yes to everything. It’s about saying NO to all but the most crucial features” — Steve Jobs

- Hidden Costs
Expose the price of new features
be on the lookout for feature loops (i.e. features that lead to more features)
For every new feature you need to…
1. Say no.
2. Force the feature to prove its value.
3. If “no” again, end here. If “yes,” continue…
4. Sketch the screen(s)/ui.
5. Design the screen(s)/ui.
6. Code it.
7-15. Test, tweak, test, tweak, test, tweak, test, tweak…
16. Check to see if help text needs to be modified.
17. Update the product tour (if necessary).
18. Update the marketing copy (if necessary).
19. Update the terms of service (if necessary).
20. Check to see if any promises were broken.
21. Check to see if pricing structure is affected.
22. Launch.
23. Hold breath.

- Can You Handle It?
Build something you can manage
Build products and offer services you can manage.
It’s easy to make promises. It’s much harder to keep them.
Consider: organizationally, strategically, and financially

- Human Solutions
Build software for general concepts and encourage people to create their own solutions
Give people just enough to solve their own problems their own way.
Example: Twitter

- Forget Feature Requests
Let your customers remind you what’s important
How do you manage them? You don’t. Just read them and then throw them away.
If you keep reading about a feature request, it’s time to consider implement it.

- Hold the Mayo
Ask people what they don’t want
Sometimes the biggest favor you can do for customers is to leave something out.
Innovation Comes From Saying No.
Filtering out the noise and get the signal

** Process **

- Race to Running Software
Get something real up and running quickly
Running software is real.
Once you’re there, you’ll be rewarded with a significantly more accurate perspective on how to proceed.
Stories, wireframes, even html mockups, are just approximations.

- Rinse and Repeat
Work in iterations
Iterations lead to liberation

- From Idea to Implementation
Go from brainstorm to sketches to HTML to coding
Brainstorm
about big questions
Paper sketches
Create HTML screens
Code it

- Avoid Preferences
Decide the little details so your customers don’t have to
Preferences are a way to avoid making tough decisions
Customers shouldn’t have to think about every nitty gritty detail
More options require more code: evil
Make the call
Examples: sorting order, number of items to display on each page

- “Done!”
Decisions are temporary so make the call and move on
Keep the momentum going
Revise if necessary
Execute, build momentum, and move on.
To me, ideas are worth nothing unless executed. They are just a multiplier. Execution is worth millions.

- Test in the Wild
Test your app via real world usage
Do it quick
1. Decide if it’s worth doing, and if so:
2. Do it quick – not perfect. just do it.
3. Save it. upload it. publish it
4. See what people think

- Shrink Your Time
Break it down
Keep breaking down timeframes into smaller chunks.
Same goes to tasks
Smaller Tasks and Smaller Timelines are easier to manage

** The Organization **

- Unity
Don’t split into silos
As much as possible, integrate your team so there’s a healthy back-and-forth dialogue throughout the process.
hire people with multiple talents who can wear different hats during development.

- Alone Time
People need uninterrupted time to get things done
Getting in the zone takes time. And that’s why interruption is your enemy.
The alone time zone is where the real development magic happens.
Set up a rule at work: Make half the day alone time.

- Meetings Are Toxic
Don’t have meetings

For those times when you absolutely must have a meeting (this should be a rare event), stick to these simple rules:
Set a 30 minute timer.When it rings, meeting’s over. Period.
Invite as few people as possible.
Never have a meeting without a clear agenda.

- Seek and Celebrate Small Victories
Release something today
Long, drawn out release cycles are motivation killers.
quick wins that you can celebrate are great motivators
“What can we do and release in 4 hours?” It could be…
A new simple feature
A small enhancement to an existing feature
Rewriting some help text to reduce the support burden
Removing some form fields that you really don’t need

** Staffing **

- Hire Less and Hire Later
Add slow to go fast
communication overhead, personality clashes
You don’t need as many people as you think.
1 great player > 4 mediocre players

- Kick the Tires
Work with prospective employees on a test-basis first
“test drive” potential employees

- Actions, Not Words
Judge potential tech hires on open source contributions
Quality of work
Cultural perspective
Level of passion
amount of time indicates how much they love programming
Completion percentage
Social match
If someone’s lacking in manners or social skills, filter them out.

If you want something done, ask the busiest person you know.

- Get Well Rounded Individuals
Go for quick learning generalists over ingrained specialists

- You Can’t Fake Enthusiasm
Go for happy and average over frustrated and great
A happy yet average employee is better than a disgruntled expert.

- Wordsmiths
Hire Good Writers
Always hire the better writer for a given job position
Effective, concise writing and editing leads to effective, concise code, design, emails, instant messages, and more.
Indicator of an organized mind

** Interface Design **

- Interface First
Design the interface before you start programming
Design is relatively light.
Hard to change code
The interface is your product
Answer these questions
Does it make sense?
Is it easy to use?
Does it solve the problem at hand?

- Epicenter Design
Start from the core of the page and build outward
you start at the epicenter and design the most important piece of content first.
worry about the navigation/tabs, footer, colors, sidebar, logo, etc later

- Three State Solution
Design for regular, blank, and error states
Regular
The screen people see when everything’s working fine and your app is flush with data.
Blank
The screen people see when using the app for the first time, before data is entered.
Error
The screen people see when something goes wrong.

- The Blank Slate
Set expectations with a thoughtful first-run experience
The blank state is the most crucial because it creates first impression!

What should you include in a helpful blank slate?
Use it as an opportunity to insert quick tutorials and help blurbs.
Give a sample screenshot of the page populated with data so people know what to expect (and why they should stick around).
Explain how to get started, what the screen will eventually look like, etc.
Answer key questions that first-time viewers will ask:
What is this page?
What do I do now?
How will this screen look once it’s full?
Set expectations and help reduce frustration, intimidation, and overall confusion.

- Get Defensive
Design for when things go wrong

- Context Over Consistency
What makes sense here may not make sense there
Consistency is not necessary

- Copywriting is Interface Design
Every letter matters
Great interfaces are written.
Examples: buttons, labels etc

- One Interface
Incorporate admin functions into the public interface
build these admin functions (i.e. edit, add, delete) into the regular application interface

** Code **

- Less Software
Keep your code as simple as possible
each time you increase the amount of code, your software grows exponentially more complicated.
Get 80% of the functionality with 20% of the time: it’s a win
Less software is easier to manage.
Less software reduces your codebase and that means less maintenance busywork (and a happier staff).
Less software lowers your cost of change so you can adapt quickly.You can change your mind without having to change boatloads of code.
Less software results in fewer bugs.
Less software means less support.
Encourage programmers to make counteroffers: say no when it’s too complicated
It’s better to inform the user using text rather than with server side code. Example: image upload format

- Optimize for Happiness
Choose tools that keep your team excited and motivated
Choose ruby for elegance and simplicity to keep the engineers happy

- Code Speaks
Listen when your code pushes back
If it takes forever to implement something, there is probably a better way

- Manage Debt
Pay off your code and design “bills”
technical debt: fixing hairy design (pay down payment) rather than keep hacking (interests)

- Open Doors
Get data out into the world via RSS, APIs, etc.
give up the idea of sealing in data. Instead, let it run wild

1. Target the right niche
The members from Vancouver Newcomers Meetup group are great. They are outgoing and friendly. This has a lot to do with the fact that majority of the members are newcomers. When you are new in town, you naturally gravitate towards making new friends. This leads to my point about targeting the right niche market. By targeting newcomers, I automatically picked those fun and outgoing individuals.

2. The importance of providing social settings
Out of all of the 25 meetup events that I have organized so far, one key attribute contributed directly to the rating that I get from my meetup members–the amount of time I allocate for the members to socialize. For example, if I start a hiking event, I always organize a “hanging out” event before the hike. These “hanging out” events can be a meetup event in a restaurant or a bar. This is very important in easing out the initial tension that members may have. In addition to this, alcohol helps. The pub crawl events have received by far the biggest interests.

3. Collaborate with other meetup organizers
Meetup organizers tend to be socially savvy. In collaborating with another organizer, you can learn a few tricks. I had the opportunity to collaborate with Jason from Atlanta. His meetup group is all about pub crawling. When he visited Vancouver, we co-organized the Sky train pub crawl. This turned out to be a wildly successful event. I have since adopted the monthly pub crawl tradition.

4. Use the right web tool for the job
There are a lot of meetup groups specialized in restaurant dining. In order to convince your member to go to a particular restaurant, you will need to promote the restaurant in some way. As an organizer, this involves doing some research on different restaurants. Yelp is very useful for finding out the best restaurants. TrAvid is also useful for achieving this. For example, here is a list of good restaurants suitable for meetup events in Vancouver. In addition, one of the feature of TrAvid is that users can find out about a place through a combination of photos, videos and twits. This provide them with a social context for meetup events.

What are some of your tips running as a meetup organizer or community organizer? What do you use to promote your startup?

Next, I will talk about some of the limitations of Meetup.com, and how TrAvid can be used as a better alternative for those on-the-fly meetup events.

In order to solve this problem, I am looking at the potentials to integrate TrAvid’s authentication system with Facebook or Twitter.

After following a tutorial session on how to use Facebook Connect and reading Facebook Connect vs Twitter Oauth, I realized that the ultimate differentiators between the two lies on
1. Time (OAuth being simpler to deal with than Facebook Connect)
2. Technology
3. How suitable these APIs can be used to leverage your website.

First, as a massive social networking website, Facebook has grown drastically from a dorm floor application to a bloated, complex and frequently-changed-so-you-have-to-relearn-everything system. This makes developing anything on Facebook a complicated task. Twitter, on the other hand, is still a simple (insert your own description) service.

Second, Facebook is developed using PHP, and the official libraries and examples are only available in PHP. On the other hand, Twitter started out as a Rails shop. This makes integration with Rails sites a relatively easier task compared to Facebook.

Most importantly, however, the real differentiator comes when you consider how these APIs can be used to promote your site. Arguably, everything in Facebook is built on friendships. There is you, and your friend, and your friends’ friends. For twitter, though, the concept of follower is relatively simpler, and less prone to complicated privacy headaches. This difference becomes painfully clear when you consider how users’ twits or messages are searched in twitter and Facebook. This REALLY is what makes Twitter such a powerful platform compared to Facebook. For business, companies can have followers. Whereas, such equivalent concept in Facebook will be absurd. That’s why they created Facebook groups to solve this problem. And for developers, this creates an extra layer of complexity to solve on its own.

So, the decision to integrate with Twitter is a no brainer for TrAvid at this point. As a one developer Rails shop that would benefit from Twitter’s Twits system. I hope I made the right decision… Now the task is to invite all my friends to join Twitter. Hopefully, they all read the following post…

If you are seeing problems like,

“Plugins::Sprockets-rails::Lib” is not a valid constant name!

make sure your version of the rails is 2.2 and above.

named_scope

I use vote_fu, but it doesn’t provide which user liked(voted up) or disliked which story, so I implemented the following named_scope for vote model:

#vote.rb
named_scope :for_voter_liked, lambda { |*args| {:conditions => ["voter_id = ? AND voter_type = ? AND vote = TRUE", args.first.id, args.first.class.name]} }
named_scope :for_voter_disliked, lambda { |*args| {:conditions => ["voter_id = ? AND voter_type = ? AND vote = FALSE", args.first.id, args.first.class.name]} }

And for user model, I have
# user.rb
def liked
liked = Vote.for_voter_liked(self)
liked.each do |voteable|
v_type = voteable.voteable_type
v_id = voteable.voteable_id
model = Vote.find_voteable(v_type, v_id)
instance_var = v_type.downcase.pluralize
instance_eval <<-EOT
if instance_variable_get("@#{instance_var}").nil?
instance_variable_set("@#{instance_var}", [])
end
instance_variable_get("@#{instance_var}").push(model)
EOT
end
end

Cache in 2.1

I used the new caching capability provided by Rails 2.1 for retrieving information for the featured destinations:

# city.rb
def City.popular_cities
Rails.cache.fetch('popular_cities') { City.fetch_popular_cities }
end

def City.fetch_popular_cities
City.all.find_all{|city| city.vote_score > CUT_OFF_LINE}
end

rescue_from

I use rescue_from to handle exceptions.

# application.rb
rescue_from ActiveRecord::RecordNotFound, :with => :redirect_if_not_found

def redirect_if_not_found
render :file => RAILS_ROOT+'/public/404.html', :status => 404
end

counter_cache

I use counter_cache for active record.

# city.rb
belongs_to :country, :counter_cache => true

on enhancing polymorphic_url

So, Rails provide edit_polymorphic_url and edit_polymorphic_path helper methods. But for my website, I have some models which can benefit from the *_polymorphic_url helpers. So, I implemented the following helper:

%w(bookmark add_tags).each do |action|
module_eval < "#{action}")
end

def #{action}_polymorphic_path(record_or_hash)
polymorphic_url(record_or_hash, :action => "#{action}", :routing_type => :path)
end
EOT
end


This allows me to call helper methods such as bookmark_polymorphic_path(@country, @city, @attraction). And from maintenance point of view, adding any more path like these would be very easy.

I hope this run down helps.

TrAvid begins with a simple idea—travel planning should not be the same as researching for a school paper. TrAvid provides quick-to-find information for a destination. Information such as restaurants, hotels, local cuisines, attractions, tours, stories and even movies filmed in a city! The information is contributed, voted and discussed among TrAvid users.

For more information, please visit http://travid.info/about.