72 <p>Twilio is a fun and lightweight API for doing things with phones and robots.</p> <p>I have a couple of "big important serious" ideas for twilio, but right now I'm just playing with it. </p> <p>Towards this 'non-goal' I remade the classic phone application of the answering-machine era: The Dial-A-Song.</p> <p>Dial-A-Song was THE classic phone application of the answering machine era. The creative band They Might Be Giants used their a Brooklyn local phone number during the eighties and nineties to play some of their songs 'on demand.' While this original service was "always busy, often broken," with Twilio's API, we can create a service serving TMBG songs that surpasses the original Dial-a-Song in functionality and robustifiability, hopefully without losing its charm. </p> <p><a href=http://github.com/jdar/dialasong>Ruby-script</a> (uses <a href=http://www.sinatrarb.com/>sinatra</a>)</p> <p><a>Rails version</a>(uses <a href=http://railscasts.com/episodes/148-app-templates-in-rails-2-3>rails-template</a>)</p> <p><b>UPDATE</b></p> <p><a href=http://docs.google.com/View?id=dg87dwbr_396g3zrgvmt>Documented notes from the event</a>, including brainstorming session of Twilio-compatible web ideas.</p> 90 2010-01-12T18:52:40+00:00 97 true 2010-01-12T18:49:00+00:00 Twilio is a fun and lightweight API for doing things with phones and robots. I have a couple of "big important serious" ideas for twilio, but right now I'm just playing with it. Towards this 'non-goal' I remade the classic phone application of the answering-machine era: The Dial-A-Song. Dial-A-Song was THE classic phone application of the answering machine era. The creative band They Might Be Giants used their a Brooklyn local phone number during the eighties and nineties to play some of their songs 'on demand.' While this original service was "always busy, often broken," with Twilio's API, we can create a service serving TMBG songs that surpasses the original Dial-a-Song in functionality and robustifiability, hopefully without losing its charm. <a href=http://github.com/jdar/dialasong>Ruby-script</a> (uses <a href=http://www.sinatrarb.com/>sinatra</a>) <a>Rails version</a>(uses <a href=http://railscasts.com/episodes/148-app-templates-in-rails-2-3>rails-template</a>) <b>UPDATE</b> <a href=http://docs.google.com/View?id=dg87dwbr_396g3zrgvmt>Documented notes from the event</a>, including brainstorming session of Twilio-compatible web ideas. 2010-02-07T09:55:21+00:00 1 38 71 <p>My brother (@meark) and I grew up playing chess against each other. It was, at times, a bitter rivalry.</p> <p>I decided to commemorate our cold-war days with a unique chessboard.</p> <p>This was done with a pre-faced board, a triangle, the power of the Internet, 10 sets of salt-and-pepper shakers, some graphite paper, and a magic-paint marker, and two beers.</p> <p>I wanted to make the black-and-white squares on this chessboard less-defined by using graphite, which would smudge over time, giving indistinct lighter-and-darker areas that roughly correspond to squares. My brother prevailed upon reason and practicality, and convinced me otherwise. Instead, a <a href=http://www.traceypackaging.com/catalog.asp?prodid=435611>spray-ink</a> was applied. </p> <p>Appologies to the graphic designer to whom I owe credit for the mushroom cloud. </p> <p>The only way it could be better would be some blinky lights.</p> 90 2010-01-12T19:03:16+00:00 98 true 2010-01-12T18:45:00+00:00 My brother (@meark) and I grew up playing chess against each other. It was, at times, a bitter rivalry. I decided to commemorate our cold-war days with a unique chessboard. This was done with a pre-faced board, a triangle, the power of the Internet, 10 sets of salt-and-pepper shakers, some graphite paper, and a magic-paint marker, and two beers. I wanted to make the black-and-white squares on this chessboard less-defined by using graphite, which would smudge over time, giving indistinct lighter-and-darker areas that roughly correspond to squares. My brother prevailed upon reason and practicality, and convinced me otherwise. Instead, a <a href=http://www.traceypackaging.com/catalog.asp?prodid=435611>spray-ink</a> was applied. Appologies to the graphic designer to whom I owe credit for the mushroom cloud. The only way it could be better would be some blinky lights. 2010-02-08T11:14:23+00:00 1 59 69 <h2>Chunky Data! Delicious!</h2> <p>One pattern that is consistently abused by Railsers is heavy-handed model associations. We create the most complex data model possible. <small>(e.g., Users have_many Interests have many FlashcardStacks have many Flashcards have many Words have many Definitions have many Tags)</small> Rails just makes shenanigans too easy.</p> <p>Ok, this all gets fixed in version two, but what is the core of the flashcard program?</p> <p><img src=http://dariusroberts.com/assets/0000/0066/flashcard_twitter.png /></p> <p>The element and source circled in red show the 'chunky data' portion of the app. This has a number of forms which are serialized into the database. Maintaining the data representation using ruby models would require additional ruby models. </p> <table> <tr> <th>Creamy (normal) </th> <th> Chunky</th> </tr> <tr> <td><img src=http://dariusroberts.com/assets/0000/0068/mockup_models.png></td><td><img src=http://dariusroberts.com/assets/0000/0067/short_window.png></td> </tr> </table> <p>I'm going to suggest that you could store almost all of these objects in flat relatively-static HTML. Serialize this HTML to the database. You could do this entire program using only two models: User and ImpressionData. The user could manipulate the HTML directly.</p> <p>I've heard of 'Data Web' and I think this is an interesting approach that is not wholly incompatible with the Rails model.</p> <hr/> <h2>THE CODE</h2> <pre><code> the pattern below is an "aggregation"... look up composed_of in the rails docs for more information. # app/models/user.rb composed_of :data_chunk, :mapping => %w(data_chunk html), :converter=>proc{|html| DataChunk.new(html) } # app/models/data_chunk.rb require 'hpricot' class DataChunk def initialize(html = "") @hpricot = Hpricot(html || "") end def to_s; to_html end delegate :to_html, :to=>:hpricot # method missing magic ... allow pass-through hpricot manipulations elsewhere in codebase? delegate :add_child, :to=>:hpricot def html; @hpricot.to_html end def html=(data_chunk); self.new(data_chunk) end def hpricot; @hpricot end def empty?; to_html.empty? end end # ... custom methods could 'seed' html with meaningful relationships... # for example, FlashcardStacks might be represented as <b>ul class='flashcard-stack'</b> # ... with many <b>li class=flashcard </b> </code></pre> <p>This is simple concept code. I will post an actual use case (from my health startup) soon. </p> <p>Please DO comment at http://twitter.com/jdar if you think I should structure this as something other than an aggregation, or if you just dislike the concept etc.</p> <hr/> <h2>NEXT STEPS -- make it legible?</h2> <p>Rails and ruby sometimes use creative method naming to communicate the importance of convention to programmers. Beginner friendly methods have short simple memorable names, while patterns that have potential for abuse are intentionally awkward to use. (see wikipedia <a src=http://en.wikipedia.org/wiki/Syntactic_sugar>"syntactic sugar"</a> and <a src=http://en.wikipedia.org/wiki/Syntactic_vinegar>"syntactic vinegar"</a>)</p> <p>Do you think we should clean up the chunky data experience, to make it a rails-worthy aggregation concept?</p> <p>Photocredit: <a src=http://www.flickr.com/photos/chrizer/3540704431/>Chrizer</a></p> 90 2009-12-10T16:52:25+00:00 95 true 2009-12-10T16:06:00+00:00 <h2>Chunky Data! Delicious!</h2> One pattern that is consistently abused by Railsers is heavy-handed model associations. We create the most complex data model possible. <small>(e.g., Users have_many Interests have many FlashcardStacks have many Flashcards have many Words have many Definitions have many Tags)</small> Rails just makes shenanigans too easy. Ok, this all gets fixed in version two, but what is the core of the flashcard program? <img src=http://dariusroberts.com/assets/0000/0066/flashcard_twitter.png /> The element and source circled in red show the 'chunky data' portion of the app. This has a number of forms which are serialized into the database. Maintaining the data representation using ruby models would require additional ruby models. <table> <tr> <th>Creamy (normal) </th> <th> Chunky</th> </tr> <tr> <td><img src=http://dariusroberts.com/assets/0000/0068/mockup_models.png></td><td><img src=http://dariusroberts.com/assets/0000/0067/short_window.png></td> </tr> </table> I'm going to suggest that you could store almost all of these objects in flat relatively-static HTML. Serialize this HTML to the database. You could do this entire program using only two models: User and ImpressionData. The user could manipulate the HTML directly. I've heard of 'Data Web' and I think this is an interesting approach that is not wholly incompatible with the Rails model. ------------------------------------ <h2>THE CODE</h2> <pre><code> the pattern below is an "aggregation"... look up composed_of in the rails docs for more information. # app/models/user.rb composed_of :data_chunk, :mapping => %w(data_chunk html), :converter=>proc{|html| DataChunk.new(html) } # app/models/data_chunk.rb require 'hpricot' class DataChunk def initialize(html = "") @hpricot = Hpricot(html || "") end def to_s; to_html end delegate :to_html, :to=>:hpricot # method missing magic ... allow pass-through hpricot manipulations elsewhere in codebase? delegate :add_child, :to=>:hpricot def html; @hpricot.to_html end def html=(data_chunk); self.new(data_chunk) end def hpricot; @hpricot end def empty?; to_html.empty? end end # ... custom methods could 'seed' html with meaningful relationships... # for example, FlashcardStacks might be represented as <b>ul class='flashcard-stack'</b> # ... with many <b>li class=flashcard </b> </code></pre> This is simple concept code. I will post an actual use case (from my health startup) soon. Please DO comment at http://twitter.com/jdar if you think I should structure this as something other than an aggregation, or if you just dislike the concept etc. ----------------------------------- <h2>NEXT STEPS -- make it legible?</h2> Rails and ruby sometimes use creative method naming to communicate the importance of convention to programmers. Beginner friendly methods have short simple memorable names, while patterns that have potential for abuse are intentionally awkward to use. (see wikipedia <a src=http://en.wikipedia.org/wiki/Syntactic_sugar>"syntactic sugar"</a> and <a src=http://en.wikipedia.org/wiki/Syntactic_vinegar>"syntactic vinegar"</a>) Do you think we should clean up the chunky data experience, to make it a rails-worthy aggregation concept? Photocredit: <a src=http://www.flickr.com/photos/chrizer/3540704431/>Chrizer</a> 2010-02-07T09:55:43+00:00 1 149 63 <p>Designing a site for multiple markets is hard enough for graphical design. I have one client who wants something that appeals to both hipsters and property managers. Challenging -- but that's why I pay my graphic designer.</p> <p>Designing an interactive web application for multiple use-cases is similarly hard, in a different way. It seems like business people who are imagineering a web application start out with the mental model of a multi-page sign-up wizard -- and then proceed additively. Challenging -- but that's why I pay ME.</p> <p>Usually I try to explain why a wizard is a bad idea, but for one recent client, I think a wizard IS the right way to go.</p> <p>Below, I explain my mental framework for WHY to use a wizard. Then see my one-method wizard hack.</p> <hr/> <p>** Decision Framework</p> <p>I propose there are two factors which should determine whether to use a wizard.</p> <pre><code> USER BENEFIT _________________ high | 1 | 2 | low |____3_____|__4__| IDEA low high COMPLEXITY </code></pre> <p>"User benefit" is the value proposition. For some ideas you need a large network of people in order for users to derive a low OR high benefit. (low:del.icio.us :: high:ridesharing) For other ideas, a single user has to fully commit in order to derive <em>any</em> benefit. (To help you shop at the store, a user would have to upload the contents of their kitchen.)</p> <p>The alternatives:</p> <ul> <li>1 simplify the UI</li> <li>2 use a wizard</li> <li>3 use a completion-reminder algorithm</li> <li>4 simplify the market *</li> </ul> <h4>simplify the UI</h4> <p>You would be surprised what a good graphics designer can do with a few splashes of color. If you've got an elegant and valuable application idea DO find a graphics designer upfront.</p> <h4>use a wizard</h4> <p>If an idea requires a 'critical mass' of information to be valuable to the end user, you might actually need to communicate this to the user.</p> <h4>use a completion-reminder algorithm</h4> <p>"You're 70% complete!" is a time-tested strategy employed by Facebook, Linkedin, etc. (See: http://xkcd.com/672/) Particularly effective for ideas which target data-intensive people (such as craigslist or ebay users.)</p> <h4>simplify the market</h4> <p>If the idea is complex, and doesn't, say, cure imminent death, you should consider supporting fewer use-cases. An API is a great idea, too. Some of my all-time favorite websites fit in this category.</p> <hr/> <p>THE CODE</p> <p>All forms on the wizard pages MUST be Ajax. You MUST title your wizard files in the format of:</p> <pre><code> # app/views/#{controller}/ 1_intro.html.erb 2_user_birthday.html.erb 3_what_do_you_want_for_xmas.html.erb </code></pre> <p>These files will be auto-located. </p> <pre><code> # app/controllers/users_controller.rb def wizard @max_page = 6 pp = (params[:wizard_page] ||= "1").match(/^(\d+)/) next_file = Dir.glob("app/views/#{params['controller']}/#{$1}*")[0] if next_file.nil? raise Exception, "No 'next page'" else # extract out just the name... e.g., "2_reminders" render :action=>next_file.split("/")[-1].split(".")[0] end params[:wizard_page] = "#{$1}/#{@max_page}" end # config/routes.rb map.connect '/wizard/:wizard_page', :controller=>'users', :action=>'wizard' # app/helpers/users_helper.rb def next_wizard_page_if_exists if params[:wizard_page] if (next_page = params[:wizard_page].to_i + 1) <= @max_page link_to("Next Page", "/wizard/#{next_page}_of_#{@max_page}") end end end </code></pre> <p><img src=http://dariusroberts.com/assets/0000/0062/mainkitty.jpg /></p> <h3><i>Disclaimer: God kills kittens when you write a Wizard.</i></h3> 90 2009-12-10T12:45:13+00:00 94 true 2009-12-10T02:08:00+00:00 Designing a site for multiple markets is hard enough for graphical design. I have one client who wants something that appeals to both hipsters and property managers. Challenging -- but that's why I pay my graphic designer. Designing an interactive web application for multiple use-cases is similarly hard, in a different way. It seems like business people who are imagineering a web application start out with the mental model of a multi-page sign-up wizard -- and then proceed additively. Challenging -- but that's why I pay ME. Usually I try to explain why a wizard is a bad idea, but for one recent client, I think a wizard IS the right way to go. Below, I explain my mental framework for WHY to use a wizard. Then see my one-method wizard hack. --------------------------------- ** Decision Framework I propose there are two factors which should determine whether to use a wizard. <pre><code> USER BENEFIT _________________ high | 1 | 2 | low |____3_____|__4__| IDEA low high COMPLEXITY </code></pre> "User benefit" is the value proposition. For some ideas you need a large network of people in order for users to derive a low OR high benefit. (low:del.icio.us :: high:ridesharing) For other ideas, a single user has to fully commit in order to derive _any_ benefit. (To help you shop at the store, a user would have to upload the contents of their kitchen.) The alternatives: * 1 simplify the UI * 2 use a wizard * 3 use a completion-reminder algorithm * 4 simplify the market * <h4>simplify the UI</h4> You would be surprised what a good graphics designer can do with a few splashes of color. If you've got an elegant and valuable application idea DO find a graphics designer upfront. <h4>use a wizard</h4> If an idea requires a 'critical mass' of information to be valuable to the end user, you might actually need to communicate this to the user. <h4>use a completion-reminder algorithm</h4> "You're 70% complete!" is a time-tested strategy employed by Facebook, Linkedin, etc. (See: http://xkcd.com/672/) Particularly effective for ideas which target data-intensive people (such as craigslist or ebay users.) <h4>simplify the market</h4> If the idea is complex, and doesn't, say, cure imminent death, you should consider supporting fewer use-cases. An API is a great idea, too. Some of my all-time favorite websites fit in this category. ------------------------------- THE CODE All forms on the wizard pages MUST be Ajax. You MUST title your wizard files in the format of: <pre><code> # app/views/#{controller}/ 1_intro.html.erb 2_user_birthday.html.erb 3_what_do_you_want_for_xmas.html.erb </code></pre> These files will be auto-located. <pre><code> # app/controllers/users_controller.rb def wizard @max_page = 6 pp = (params[:wizard_page] ||= "1").match(/^(\d+)/) next_file = Dir.glob("app/views/#{params['controller']}/#{$1}*")[0] if next_file.nil? raise Exception, "No 'next page'" else # extract out just the name... e.g., "2_reminders" render :action=>next_file.split("/")[-1].split(".")[0] end params[:wizard_page] = "#{$1}/#{@max_page}" end # config/routes.rb map.connect '/wizard/:wizard_page', :controller=>'users', :action=>'wizard' # app/helpers/users_helper.rb def next_wizard_page_if_exists if params[:wizard_page] if (next_page = params[:wizard_page].to_i + 1) <= @max_page link_to("Next Page", "/wizard/#{next_page}_of_#{@max_page}") end end end </code></pre> <img src=http://dariusroberts.com/assets/0000/0062/mainkitty.jpg /> <h3><i>Disclaimer: God kills kittens when you write a Wizard.</i></h3> 2010-02-08T20:41:06+00:00 1 196 65 <h2>PhotoCredit: <a src=http://peterprato.com/2009/12/02/some-are-more-obvious-than-others/>my friend, Peter Prato, who makes living an art in-and-of-itself</a></h2> <p>Forget RTs.</p> <p>The Tweeps who matter are standing in this picture.</p> <p>The everytweep is the tweep who is outside enjoying the sunshine with friends.</p> <p>Don't give them content to tweet about. Give them sunshine and friends.</p> <p>You know who you are.</p> <hr/> <p>I was conversing with a social media expert. </p> <p>He stated a Twitter corporate strategy declaratively -- claiming twitter was already working with google, and that google should shortly be the way to access tweets.</p> <p>To which I replied:</p> <blockquote> <p>I saw the partnership announcement and wondered what the actual data provided to google would be. One interpretation is certainly that twitter decided to move in the "advertising in tweets" direction. Twitter certainly could subsist on a few scant millions from Google. I find this unlikely. Google already has enough information about twitter's users from indexing the public timeline that it's only a matter of time before they start carving off markets. (using wave, most likely) Given Twitters' risk-savvy investors and roots they really should be aiming for a winner-take-all strategy, and keep selling on the table. (the null-hypothesis strategy, really) Rather than advertising, I think this would mean some sort of identity-play through "personal reputation" or "value-add search indexing". I would say distribution infrastructure innovation... but I think all the potential purchasers are already well ahead in that field. In any event, this has little relevance to the non-profit people on PX. I just nettled when I saw the declaration. I'm of a different opinion, but it's certainly open for debate. If I were advising PXers on "twitter strategy" (Ha!) I would probably suggest a framework for understanding the effect of real-world meetups</p> <h2>of supporters, and the roll that twitter plays in those.</h2> </blockquote> 90 2009-12-10T19:59:51+00:00 96 true 2009-11-01T19:38:00+00:00 PhotoCredit: <a src=http://peterprato.com/2009/12/02/some-are-more-obvious-than-others/>my friend, Peter Prato, who makes living an art in-and-of-itself</a> ------------------------------------------ Forget RTs. The Tweeps who matter are standing in this picture. The everytweep is the tweep who is outside enjoying the sunshine with friends. Don't give them content to tweet about. Give them sunshine and friends. You know who you are. ------------------------------------- I was conversing with a social media expert. He stated a Twitter corporate strategy declaratively -- claiming twitter was already working with google, and that google should shortly be the way to access tweets. To which I replied: > I saw the partnership announcement and wondered what the actual data provided to google would be. > One interpretation is certainly that twitter decided to move in the "advertising in tweets" direction. Twitter certainly could subsist on a few scant millions from Google. > I find this unlikely. Google already has enough information about twitter's users from indexing the public timeline that it's only a matter of time before they start carving off markets. (using wave, most likely) > Given Twitters' risk-savvy investors and roots they really should be aiming for a winner-take-all strategy, and keep selling on the table. (the null-hypothesis strategy, really) Rather than advertising, I think this would mean some sort of identity-play through "personal reputation" or "value-add search indexing". I would say distribution infrastructure innovation... but I think all the potential purchasers are already well ahead in that field. > In any event, this has little relevance to the non-profit people on PX. I just nettled when I saw the declaration. I'm of a different opinion, but it's certainly open for debate. > If I were advising PXers on "twitter strategy" (Ha!) I would probably suggest a framework for understanding the effect of real-world meetups of supporters, and the roll that twitter plays in those. ---------------------------------------- 2010-02-07T09:56:02+00:00 1 130 61 <p>Thought this (sampled, corrected) statistical analysis from the creator of OKCupid.com was really interesting.</p> <p>Race is taboo subject (see the "Bradley effect"), which is all the more reason that important to look for solid indicators. Dating is valid from a sociological viewpoint; "Interracial Marriage" is a key indicator of race relations. </p> <p>More: http://blog.okcupid.com/index.php/2009/10/05/your-race-affects-whether-people-write-you-back/</p> 90 2009-10-14T14:23:07+00:00 92 true 2009-10-14T14:12:00+00:00 Thought this (sampled, corrected) statistical analysis from the creator of OKCupid.com was really interesting. Race is taboo subject (see the "Bradley effect"), which is all the more reason that important to look for solid indicators. Dating is valid from a sociological viewpoint; "Interracial Marriage" is a key indicator of race relations. More: http://blog.okcupid.com/index.php/2009/10/05/your-race-affects-whether-people-write-you-back/ 2010-02-07T09:56:07+00:00 1 285