trendpreneur

10K Apart is a nifty little contest I heard about from @limedaring (and if you haven’t seen her work or her co-founder post, I thoroughly recommend doing so). The concept’s pretty much as it says on the tin: do something nifty in under 10K. Of course, most of the highly interesting-looking apps submitted so far make liberal use of the “external API” provision; these days, you can outsource the logic, so why not?

The deadline’s on the 25th (next Wednesday) so if you have time but lack inspiration, here are ten things I would be looking at building if I weren’t so busy performing advanced CPR on FestBuzz. (Which, by the way, has up to date listings now! So it’s *half* done…)

In no particular order, and with no particular guarantee any of these are achievable within 10K (but several probably are):

Collaborative short story improv/writing

Much like those round-robin fold-over note stories you used to do as a kid (surely they had a proper name). Each successive visitor adds a sentence blindly, or with the last sentence only on view. At some predetermined N sentences, the entirety is revealed and everyone who submitted a part is notified. Probably needs some kind of web database API.

Minify/10K This

Meta-apps are fun. Could you write an app that, given another app, minifies it and tells you if it’s under 10K, with suggestions for compression? I’m sure you could.

Petrol Money Jar

For the love of god, give this a better name. This is something that could be 10K, probably won’t be, but could qualify as part of the X.com PayPal developer challenge too. Bumming lifts off friends all the time gives you a residual level of guilt. Automatically pay your mates via PayPal when they’re filling up at the petrol station; simplest version is just a pre-filled one-click “Give my driver $10″ button, but think of what you could do with geo and mobile. Track the journey, track the exact petrol station and thus the gas price, enter in the car’s make and model to get the average mpg, and get exact petrol division. Kapow.

Twitterfluff

Enter a website you like (RSS feed) or account that you follow more or less religiously. Enter a time period. Twitterfluff retweets for you every day/few hours with a randomly generated commentary comment to make it look less artificial. E.g. “RT @TechCrunch AT&T Still Not Connecting Calls http://tcrn.ch/abcDE << SO true!!”

Siteroulette

Did you ever visit that site where you typed in a Google search and got the search the person before you had typed in? Kind of like that, but with URLs instead (filtered!), or youtube videos, or…

Beautiful Reddit

Take Reddit. Make it look nice. Similarly, Hacker News (which is beautiful in its elegance, but still, this is a design contest and I’d love to see what concepts people could come up with).

Paper on a Plane

I haven’t found a good implementation of this, though I’m looking. It definitely is relevant to my interests. Anyway, a good, Instapaper-esque but-using-HTML5-LocalStorage-probably, way of saving articles to read later – so when I’m on a plane, I can catch up on the longer, meatier stuff. And, one day, videos too. (A girl can dream.)

Presentation Mode

A conference-style presentation view of tweets, and possibly other social media mentions, of a keyword (conference hashtag) – ideally with some filtering, especially for repeats. Seen this done a lot, always ugly (even the one I built). App for monitoring audience Q&A via twitter on the same hashtag would be cool, too, e.g. with Google Moderator style voting.

Super Magic Awesome Boredom Eliminator 2000

This idea comes from “Hmm, what’s a nifty web API I could use that nobody else might be tapping”. Use Directed Edge’s recommendations API and Netflix’s dataset [or anyone's, really] plus some radical 1950s soapbox style design to create an app where users type in something they enjoy, and the Super Magic Awesome Boredom Eliminator 2000 tells them what they should watch/do next. Add user suggestions for extra sparkle.

Note: I spent an entire evening hacking around with the Facebook API to see if I could work some sorcery here to do with liking and friends and recommendations and stuff, but no dice. In case you were going to try.

URL! URL! URL!

A mix of the above, and siteroulette, with your own personal sprinkling of inspiration. Kind of like Alltop but basically reduced to a big shiny red button. Pick a category (heck – you could use Alltop to seed it). Voila – a constant URLfest of cool links within that category. Whether tweetmeme, personal twitter feed, the Technorati, or Reddit’s /img section seeds it – all you have to do is press play. Possibly better as a Chrome extension; possibly already exists as a Chrome extension. Oh well.

If you do implement any of these ideas, ever, give me a shout – I’m interested to see what turns up. Good sailin’ to ye.

I’m no secret admirer of O’Reilly’s fantastic technical books, so when I saw there was a new iPhone app book coming out, I got pretty excited. I’ve been meaning to dive into iPhone app development for a while now, and the advent of the magical piece of magic iPad has certainly made me more keen to do so.

Enter ‘iPhone App Development: The Missing Manual‘. (Book website)

This book by Craig Hockenberry does a really decent job of conveying the experience of being an iPhone app developer, not just the technical documentation. It contains details on Japanese tax treaties, beta testing and bug-hunting, MVC and paper prototyping. It’s more like a course on the lifecycle of an app than a detailed lesson in programming for the iPhone, something that the other iPhone books I’ve read have handled in a fairly clunky manner.

Any criticisms I have for the book’s content are not really the fault of the author, but more the ’standard’ way of teaching iPhone programming, and the constraints within which a tutor must work. Number one, I am fed up of flashlights. Seriously. I’m also pretty bored with the whole “Create an app without any code!” approach.

It seems every single newbie tutorial out there tries to schizophrenically assume you have little to no programming experience, and would rather build something with as little of that nasty code as possible, while also jumping in with details on the square brackets and types and inheritance from the get go. I don’t know. There must be a better way.

Craig’s book actually handled this better than most, and I found myself bookmarking nuggets of wisdom early on, which is useful. Let’s just say, however, I’m not following it through from start to finish. Rather, I’m using it side-by-side with the iPhone Developer’s Cookbook, which is a real joy in the ‘I just want to build cool shit’ department.

If you’re the sort of person who likes following a single tutorial through without branching off on tangents though, I think you’d be more than pleased with the Missing Manual. You’ll definitely deep-dive into some nifty Objective-C syntax and Cocoa Touch specifics, tools and tricks that are used by actual developers (no, really, I googled some of them!). You’ll learn a lot about designing, testing and releasing your app along the way, too, which is great.

I’d love to see this book done as a class, actually, it definitely reads to me that way and I think it could be nicely broken into work segments. I aim to finish it and see how long the whole thing takes, for sure. I’m learning a lot, and not just about flashlights — I just can’t help it if I get distracted every once in a while and make a twitter app or tip calculator to pass the time…

Definitely worth a buy if you’re starting out with iPhone app development and ideally have some OO experience, just don’t expect it to be your only go-to book.

I recently idly tweeted an idea which flitted through my head while considering the pros and cons of “E-School”, the Founder Institute. People asked for more, so here it is!

To build a business you need to build a product. While technical types often find the process of knocking up a quick demo webapp a walk in the park, one way a non-technical person can quickly gain feedback and respect is to build a prototype themselves.

If you have an idea for a web application – whether it’s a shopping site with a twist, an iPhone app that shows you nearby tweets, a game to teach children about finances, or a global treasure hunt – chances are you can build an early version to get the idea across quite quickly, even without much of a background in computer science.

Today’s tools are accessible and almost universal, but they can be really daunting if you don’t know where to begin. The value of creating your first prototype yourself in terms of feedback, understanding the problems you’ll have, and even the exercise of trimming down the feature set and figuring out the MVP (minimum viable product) is far, far greater than the time saved outsourcing it to the Philippines.

But where are the tools to teach you how?

There’s stuff to turn hackers into entrepreneurs, but connecting entrepreneurs with the tools hackers have at their fingertips seems much less common.

Here are some of the ideas I have around creating a resource (offline workshops? week-long intensive? online course? incubator? unconference? wiki? website/blog? book?) to help people without a technical background build a prototype of their idea quickly, and get feedback on it.

Methods

• How to design, structure and plan a web application (see below for how to build)
• Rapid prototyping, iteration, and agile development (i.e. build it quickly, get feedback, change it)
• Minimum viable product and how to figure out what should be in your prototype
• Ways to test out your application; how to find initial users and get feedback (Real stories)
• Feedback channels for prototyping before you’ve written a line of code
• How to pull off an awesome investor demo (Interviews)

Technology and Tools

• Product and feature design techniques
• How to make the most of paper prototypes
• What’s wireframing and why should I bother? Won’t the designer do that?
• Designing an awesome user experience
• Visual design basics (Analysing/Breakdown of beautifully designed prototypes)
• How to make things look good and feel polished without a degree in graphics
• Readily available tools and products you can use to speed this along

Getting Help

• Ideally, build everything yourself; it really helps your credibility and teaches you a hell of a lot along the way. If this isn’t an option for whatever reason,
• How to outsource the building of a prototype
• How to find a developer and/or designer
• Once the prototype is built and you’re happy, how to find the right rockstar lead developer to take it forward

I’d love to hear some feedback on this idea and information on areas you particularly want to learn more about (whether I included them or not) — and how you’d like to consume the information.

Cheers,
Jen

Startup Weekend is an awesome concept. Strangers get together, pitch ideas, spontaneously form teams and by the end of a weekend have a working demo and pitch to show everyone else. As an attendee at last weekend’s Bay Area event, it was truly amazing to see the number of things built literally-from-nothing over 48 hours.

I’m a hacker-entrepreneur. I love to create ideas, turn them into business concepts, and then realise them in code. However, at Startup Weekend it seems the skillset of attendees can range from ‘just here for the ride’ to ‘hardcore $language programmer’ to ‘I love writing business plans’. Here are a few things I learned from the experience.

1. Pitch your own idea.

I didn’t. Then I remembered an idea I’d previously had about halfway through the weekend and was kicking myself for not pitching it. I definitely believed in the problem my team was solving, but I think there’s just a different energy level and focus, especially for me, when it’s your own idea. It would also have given me a better role to play during the weekend, that of leader/visionary/hole-filler/driver, rather than head-down hacker (which was a fun role to play, but I learnt over the weekend that it isn’t the role I enjoy most, any more.)

Even if you don’t get a team for your idea, pitching your own idea tells people a bit about who you are and why you’re there.

2. Pitch your problem, not your solution.

For both the kickoff night and the final presentations, the mantra ‘problem not solution‘ is key. Once the problem is clear, dive into the solution, but you gotta get buy-in on the whole reason you’re doing it. A few of the Friday night pitches asked the audience “How many of you…?”. Easy way to validate your problem and ditch the whole thing if nobody responds.

As the backchannel on Twitter said so clearly, if we don’t get it within 30 seconds, there’s something up.

3. For the love of god, don’t pitch something outside the scope of Startup Weekend.

I can’t believe how many people pitched existing companies (they were hiring, etc) or projects that were not Startup Weekend projects (here’s this thing I’ve previously built and I’ll drone on about it incomprehensibly). Whatever you already do, put it aside and embrace the creativity of 48 hours of collaboration.

4. Pick the team you can help most.

Friday night, picking a team, was tough for me. There were three teams whose ideas were pretty close, all problems I could sympathise with, and all ideas where my expertise could come in handy. I picked the team whose problem seemed the most in need of my speciality, where I thought I could make the most difference. Maybe this is just a cue to build a platform that I can license to all the teams…

5. Someone else will have the same idea.

One of the similar teams ended up pretty much building the exact same product idea as us over the weekend, which was quite amusing. Don’t sweat it. It just shows the problem you’re solving is real. If they do a better job, ask yourself why!

6. Don’t have too big a team. Especially if you lack technical direction.

We had six developers total, I think. Even now I’m not really sure what everyone did. We all used different platforms and languages, and nobody really understood how to put it all together. I didn’t even see working code from anyone else all weekend. Communications failure on my part, and role failure (nobody stepped up to be technical lead). I think we would probably have achieved a better, more-featured demo with only two developers both using the same platform.

7. Know what you’re being judged on and focus on it.

We also had a ton of business people, who contributed greatly to the business behind the idea – we had a business plan, I think we had financial projections, a twitter account, etc. The problem is that the weekend was being judged, almost entirely, on the strength of the idea and the potential of the solution. No time or reason to show slides on potential market cap, earnings in year 5, etc.

I think if you’re a business person, and you’re super awesome at financial models and market cap and P/E ratios and all that, and you want to contribute to Startup Weekend, you still can. Just don’t focus on one team and build out their investor deck when they haven’t even got a line of working code yet. Go around the teams and see if you can spend a few hours with a few different ones, helping them out. Or take on multiple roles for your team and man the twitter account, get some test users signed up, do some fake data entry, mock up some UI in Powerpoint, whatever. Make tea. Contribute. There’s a place for Excel, it just ain’t here.

8. Market research is awesome.

We sent out two surveys (one via askyourtargetmarket and one a Google Form) on the start of Saturday to validate part of the problem and get feedback on possible solutions. This process was really useful for streamlining some of the thinking higher-level, but we didn’t really have enough time to incorporate it fully.

9. Drink lots of water, not soda. Eat well. Sleep better.

There’s something appealing about staying up coding for 48 hours straight, but (especially if you have a day job to go back to the next day) looking after yourself is even more appealing. I put my survival through the weekend down to a lack of sugar, fat and general yuck. Too much pizza on offer, fortunately I couldn’t eat any of it.

10. Fail fast.

The advantage of prototyping and validating an idea in a weekend is the speed at which you can fail, and learn. If it isn’t going to fly, accept it and move on. You’ve ‘wasted’ a weekend, but there will be plenty of things you can re-use from the experience.

This is where the whole MVP/iterate thing comes in, too. If you’re not being lean, you won’t fail fast enough in the weekend to actually get something useful out of the experience.

11. Have funny pictures on your slide deck.

If all else fails, do an entertaining pitch at the end of the weekend and you’ll keep the fun factor high. (Bonus points if you do an entertaining pitch and seem to have built a working product!)

(Here’s another attendee’s take on lessons learned from Startup Weekend, too.)

OK, OK, so I already tweeted this, but it’s interesting. Hillary Mason set up intelligent email autoresponders to deal with repetitive email enquiries and politely nag people for replies. It’s good stuff, and something I’ve never really got around to doing myself, for a couple of reasons (besides the obvious); I use Gmail, and to be honest, no two emails I send are the same.

(It’s an interesting overlap with Project India, by the way… I don’t know why I’m so excited about this year’s Group Projects. Either because they’re kind of real, or because I miss academia. Or both?)

The downsides of using Gmail haven’t really affected me personally, but thinking about it, I would like to be able to actually access my raw email to set up better, NLP-based filters. I have a lot of email filters, and a lot of labels, and a system that just about works (thanks to superstars and multiple inboxes). But, you know, it could be better, and despite IMAP access it doesn’t quite flow; if I wanted to process mail, I’d have to access it all on a random box, and then what? I can’t apply Gmail labels or superstars or mark as read, can I? I guess what I really want is to operate on both the protocol/content and the interface itself, and that’s asking a wee bit too much. Oh well. Time to hack on a communication platform that I can play with…

(credit to Craig, who linked me the video, and will complain if I don’t acknowledge his genius.)