Closing the Loop – Twitter Commerce

To say that brands are trying to figure out the best way to use Twitter to drive commerce would be an understatement. The massive opportunity the Twitter platform presents for commerce has not been lost on Twitter CEO Dick Costolo.

Currently the extent to which brands drive commerce on Twitter is limited to broadcast advertising. Brands send out Tweet based ads designed to lure consumers from Tweetdeck to the brand storefront. A transaction is then still multiple steps away as consumers must pass through a traditional e-commerce checkout process.

Semil Shah has recently written a lot about discovery based commerce. In his TechCrunch article How Discovery Will Drive Transactions he discusses the changing landscape in social commerce from search to discovery based following. He actually mentions Sell Simply in the article as a payment system. But, we’re much more…

The transition from intent-based search on Google, to discovery based commerce, is absolutely occurring, and is a perfect example of how we take Twitter to another level in the commerce context. Since we enable transactions on Twitter (one can Tweet an item for sale — followers can buy simply by replying), we actually complete the circle from discovery (you’re following a brand selling something) to action (“reply to buy” payment)… all with two Tweets. Consumers do not have to leave the Twitter platform to transact. Brands sales percentage exponentially increases as frictions decrease.

In other words, we not only drive social commerce from a discovery standpoint, we go one step further and close the loop by enabling transactions on the same platform the discovery is taking place. With us, Twitter is no longer confined to just a broadcast platform for brands. When brands Tweet about a sale through Sell Simply their followers can purchase directly from the Tweet. This combination of social commerce with “reply to buy” transaction capability is what makes our platform so powerful.

The transition from search based commerce to social is on. We’re happy to be a part of it.

 

Chrome Extension: Sell your Etsy, Ebay or Craigslist items directly on Twitter

Promo_screenshot

This weekend I created a Chrome Extension for Sell Simply that allows you to Sell your Etsy, Ebay or Craigslist items directly on Twitter.

The extension let’s you to Tweet your items for sale directly from the item listing wherever it may be. People can then purchase the item just by replying to the Tweet with the word “buy”.

Sell Simply on Meet The Startup

I was recently interviewed by Rick Turoczy about Sell Simply for Meet The Startup.

The interview went super smooth, mostly due to the relaxed nature of Rick, and the obvious benefit of knowing your own startup inside and out. Thanks to Rick, Tom Turbull and Phil Kinjerski for their work promoting startups in Portland. I’m glad to have the opportunity to discuss Sell Simply and the direction it’s taking.

If you have a chance go check out all the Portland talent in the archives of Meet The Startup.

Flickfolia

Screen_shot_2011-06-18_at_9

Flickfolia is a professional photography portfolio you can control entirely with your Flickr account.

Here are some features in brief. More on the site.

Control Freak
Control navigation, colors, layout, fonts, logos and all photos with your Flickr account.

Everwhere? check!
Flickfolia works on any device as well as the web. Plays nice with Google. Impresses on the iPad, and is very touchable.

Your Place, Your Stats
Flickfolia can live at your domain or ours. All stats can be viewed with your own Google Analytics account.

Calvin Coolidge was the man (with numerous awesome pets)

Rob Roy and Prudence Prim – White collies
Peter Pan – Terrier
Paul Pry – Airedale Terrier
Calamity Jane – Shetland Sheepdog
Tiny Tim and Blackberry – Chow Chows
Ruby Rouch – Collie
Boston Beans – Bulldog
King Cole – German shepherd
Palo Alto – Bird dog
Bessie – Collie
Rebecca and Horace – Raccoons
Ebeneezer – Donkey
Nip and Tuck – Canaries
Enoch – Goose
Smoky – Bobcat
Tiger – cat
Tax Reduction and Budget Bureau – lion cubs
Billy – Pygmy hippo
A Wallaby
A Duiker (a very small antelope)
A black bear

Source: wikipanion

Top 20 post on Hacker News – The stats

Last night my previous post made it to #17 on Hacker News. These are the resulting stats as of this morning.

11 Likes
4000 uniques
15 seconds avg. on site – people skim, and skim poorly
50% on Chrome. Yay geeks!
43 Karma points on Hacker News

I’m not a frequent Hacker News poster, so this was pretty fun.

Screen_shot_2011-02-27_at_12
Screen_shot_2011-02-27_at_12
Screen_shot_2011-02-27_at_12
Screen_shot_2011-02-27_at_12

Why I never design a site in Photoshop

I have designed and written the code base for a lot of websites and applications over the past 14 years. I have never once designed a site in Photoshop.

It is true I design some elements in Photoshop, but as far as site layout, nav, ui, ux, color etc… I design in code from day one. A recent post by Joel Lewenstein on Rebekah Cox‘s design process at Quora made me feel all warm inside that I’m not alone.

My workmates and other designers that see me use this methodology are appalled. Most think it leads to refactoring and inefficiency. They’re most certainly right on the latter, and most certainly wrong on the former. Here are a few reasons why:

On refactoring
Refactoring is not something to be reviled. If you’re refactoring it’s for a good reason. Typically that reason is born from the desire to improve users experience, or add a new feature. Refactoring a design in Photoshop is extremely inefficient. In fact, it’s a complete waste of time. It’s much easier to alter my css on the fly then go back into Photoshop, mock up a change, then try and port that change across layer comps. Furthermore, in Photoshop inconsistency creeps. You slack, because it’s arduous to bump pixels to perfection across multiple layers and comps. To use a programming term, Photoshop is not object oriented. The end result is layer comps that differ from one another. Inconsistencies, and lazy web syndrome. If you’re doing design right, you should be constantly refactoring.

On environment
Designing interactive experiences in Photoshop is like baseball practice with trees. Trees don’t react to the ball. In Photoshop nothing is interactive. It’s a static representation of what the application will become. Why would you ever design an immersive experience in a catatonic state? When you design in code the application is realized in it’s natural state. Incremental improvements are seen in real time. User experience gains are substantial because you are actually using your design while designing.

On efficiency
Designing in code is fast. I’m not talking a little bit faster than Photoshop, I’m talkin’ exponential returns. Starting simple with a header, footer and content div, and some css, you can realize the base layout, style, and color in short time. Once this stage is complete guess what? You’ve just built a prototype. On to user experience. This is a breeze because again, this thing is starting to breathe. This prototype lives where? On the Internets, where reviews can be made by decision makers on the fly. With reviews come revisions. But, those revisions are not frustrating, they’re easy to make. Your code is object oriented. Changes sweep across pages. Whole design phases are cut in half. Your prototype is now ready for iterative improvements straight through development.

Photoshop and other design tools certainly have their place in the interactive design process. Accomplishing imagery and a gorgeous design is tough without them. However, they shouldn’t be used for the main components of interactive design, iterative feature updates, or user experience. They get in the way, make you lazy, slow you and the project down, and result in a decrease in quality.

Of course, to realize the potential of this methodology your designers need to be programmers, know how user experience is built (not imagined), and understand fully the medium for which they are designing for. I’ve argued this point for years. For brevity sake I’ll just say it again: Designers should develop and developers should design. Devigners.

CodeIgniter Upgrading from 1.7.2 to 2.0.0

After digging a bit I got the upgrade to work. Here is what I learned, hopefully it will help you avoid pitfalls if upgrading from 1.7 to 2.0.

I’m a noob to CodeIgniter, so these changes may have been obvious to those who are not. That said, these changes were not mentioned in the upgrade instructions.

Along with extending CI_Model and CI_Controller you must also change the way you call constructors in Models and Controllers to the following…

function __construct() { parent::__construct(); }

You must move your /applications folder to the root along side /system

As far as any changes to files in your /application folder, I’m taking them one by one. /config.php definitely has changes within it. I’m going through and changing methods instead of replacing files. If anyone knows of documentation that covers upgrading files inside the /applications folder please let me know.