iPodLCD.jpgLast Girl Scout Cookie Season, Riley was out with Berta and Abby at one of the tables they had set up to sell cookies near Acme. He had taken his iPod Touch with him to keep him occupied, and it was doing a good job. As they were cleaning up, he accidentally dropped it on the sidewalk and cracked the screen.

Obviously, Riley was upset because his iPod was broken, and Berta wasn't inclined to buy another one, since we had gotten the pair of them at a deep discount that was unlikely to happen again. I suggested repair as a possibility, having had friends repair iPhones and the like, so we started down this long road.

The image worked fine, but the glass was broken, so Berta ordered a replacement digitizer with glass. This could have worked fine if I was more delicate with the parts, I suppose, but I cracked the display while trying to remove the old digitizer. Seriously, these things were not designed to be user-serviceable; there is adhesive everywhere inside. Frustrated with the operation, I declared the screen dead, and we had to order a whole new display and digitizer.

The new screen finally came recently. Last night I tried to put the screen in. It worked, but there were some issues. First, in my frustration I apparently chucked the old cracked screen, and the home button along with it. Since the replacement parts don't come with a new home button, I had to order a new one last night. $5 for a dumb little plastic button I could have saved.

The second problem is that the camera doesn't work. I must have knocked something out internally when I reassembled the device. This is really disappointing, because the primary reason I got the iPods for the kids was so that they could document their lives in photos/video in a way that I didn't when I was growing up. If Riley doesn't have a ready camera, it basically relegates him to using the iPod to play dumb, free petshop games. (Yes, he could use it for other stuff, but he doesn't.)

In all, we've not spent as much in parts as buying a new iPod. But the frustration and time taken to do the repair haven't taught me anything other than I don't want to be an iPod/Apple repairman. Maybe next time, I'll pay an expert to do the repair.

calendar.jpgLooking at the calendar on my phone, which is connected to several Google calendars, I see a mess of events. There are things that are scheduled for specific times of day, and there are things that are scheduled for "all day". That's what's bugging me today, the "all day event".

There are some events that really are "all day". For example, there are some trips that we're taking that encompass the whole day. But other events, like birthdays and "last day of school", are not really "all day". They're kind of milestone markers; this is the day this happens, but it's not something that will keep you busy all day, just something of note.

I would like for these events to show up as icons of some type to differentiate themselves from the true all day events. If the event causes me to have "busy" time during the day, it should show up as a bar of allocated time. If it's just "this is Washington's birthday", then it should just be an icon on that day.

Also, there are other events that get dropped into the calendar that are merely reminders that an event takes place on a specific day, but don't have exact times associated with them yet. The Pickering Valley Elementary School Art Show is a good example of this. It's on the 17th, but I don't know what time yet. I'd like a kind of visual alarm to tell me that this is not an "all day" event (like a birthday I can ignore), but an event I need to plan a time to be available for.

I really like my phone calendar, Calvetica. This isn't really a shortcoming of the software, I feel, just something that mobile calendars don't do in general. I think the issue I describe is due to a shortcoming in the caldav protocol that is used to transfer calendar data around the net, but I'm not enough of an expert on it to be sure. Still, I wonder if it would be possible to extend everything usefully this way.

charger.jpgI travel with my notebook, probably not as much as many people do, but enough. One of the heaviest things in my notebook bag is the notebook charger. For whatever reason over the years, the design of notebook chargers has not improved at all.

I have been using a Targus travel charger for a while now, which fulfills a couple of my specific wish-list criteria concerning chargers, but not all:

  • The transformer unit should be small and lightweight.
  • All cables should be able to fully disengage from the transformer.
  • The charging tips should be interchangeable/exchangeable for future compatibility.
  • The unit should be able to power more than one device at once, preferably the the notebook and some USB device (like a phone)
  • The unit should be outlet neutral, both consuming an outlet and providing a pass-through outlet so that there is a zero sum of consumed outlets
  • The plug on the unit should be able to fit in tight spots without the transformer blocking other outlets.
  • The wires on the unit should be long enough to provide reach, but not so long as to add 10 pounds of conductive copper to my bag.
  • The wires and charging tips should come with some useful cable/component management, so that they can be easily organized and stowed.
  • Surge suppression would be nice
  • Very, very short UPS (like, enough only to pull out the plug and plug it into another outlet) or internal battery power enough for a USB device or two (ala the Zagg Sparq I already carry) would be nice.

A recent change to my equipment list has at least temporarily rendered my Targus charger obsolete, since they don't offer a charging tip that will fit my device. As a result, I've been looking for a travel charger that might better fit my criteria. Sadly, I've not been able to find anything that fits all of my criteria. I've looked at ioGear's Anywhere Charger, but it doesn't have the right tips, not to mention that you can't disengage all of the cables from the transformer (this lack-of-feature drives me crazy).

There are any number of off-brand chargers that will charge one device at a time, but the only thing I can imagine is worse than having to carry a bazillion charging cables because the devices all use different plugs, is to have to carry a bazillion transformers for the same reason.

Ideally, Targus should just make the charging tip that I need, then I can just pay for that tip and move on. But it looks like the odd power requirements of my device aren't handled by their transformer, or the device is too new to have a supported tip yet.

Philly Startup WeekendLast Friday night was the start of my first Startup Weekend, and I didn't know quite what to expect. In fact, the logistics of getting me into the city from the suburbs for such long days had me thinking I should just give up my ticket. But I manged to wrangle accommodations down the street from the University of the Arts where the building was held, and arrived just in time to join those gathering for pre-event drinks and snacks.

I grabbed my badge from the table and started talking to people. If you know me at all, you're already thinking I'm making stuff up -- I am not usually so social. But Startup Weekend, unlike most other events, is not an event that you attend passively. You interact with other people or you don't experience it. Within the first 20 minutes of the event, I met and had great conversations with two people who went on to form teams that won second and third place!

The weekend starts out with everyone in an auditorium to learn about the event. They talk about the prizes (of which there are basically none but accolades and a presentation slot at Switch Philly for the top team -- haha, more work!) and the schedule and cover a few of the basic things that everyone new - like me - must be wondering. While waiting in the auditorium, I met a few new folks, specifically seeking out people with a "Designer" name badge.

When you register for the event, you can choose one of three identities: Developer, Designer, or Non-Technical. Having met some of the "non-technical" folks, I wouldn't call them that. My impression was that although there was a fair percentage of non-technical attendees, developers were far and away the most abundant, with designers trailing a far distant last place. I don't understand why this is. Maybe it's the marketing and how it tends more toward developers and entrepreneur-types from local business schools, but the University of the Arts is right there... Am I to believe that user experience design is not as commonly taught a discipline? (Hey, artists! Wanna make money doing art?... Get into UX!)

After the introduction, we were ushered to the atrium, a larger room that would become our workplace for the next two days. In the atrium, we gathered at tables based on random numbers stuck to our name badges. We were given some direction about making pitches, which are an essential part of Startup Weekend. At the table, we found written two unrelated words, and as a group each table needed to come up with a product and a pitch for that product.

The words at my table were "Nickelback" and "Whistle". Our pitch was for a product called "Whistleback" (obviously). The pitch went something like, "Hi, I'm Owen and I want to talk to you about Whistleback. People who really know their music are tired of unchallenging 'Name-That-Tune' games where the music is too easy to guess. That why we've built Whistleback. Whistleback picks a Nickleback song at random and whistles it to you, after which you must identify the song to earn points. The game is hard because all of Nickelback's songs sound so similar! Try it out - Whistleback!"

Pitches have vital components. The name of the product, the problem it solves, and how it solves it are all vital. The presentation style is important, too, naming the product at the beginning and end so that it sticks in the head of the audience. Being charismatic helps a lot. I felt bad for many of the people pitching later on who seemed to have very interesting ideas, but had difficulty articulating them, whether due to not following the structure or problems speaking English well. But all of the tables did a pretty good job of pitching in this round.

Our table didn't win this round of pitches as decided by the organizers. Another table, presenting "Guerilla Ice Cream", a product for moms to disincentivize their kids to treats, won the honor of presenting their real pitches first.

And so the pitches began. 43 in all. There were some good ones, some not so good ones. Even I pitched a website that would mine your Facebook account for music preferences and then sell you tickets to bands you like so that you don't ever miss a concert for your favorite bands. My pitch read like this: "My friend called me last night and said, 'Hey Owen, where were you at the concert last night? It was awesome!' Man, I am so tired of missing concerts of my favorite bands. That's why I want to build StageDrive. StageDrive is a website that mines your Facebook profile for information about bands that you and your friends like, then tracks when tickets for those bands go on sale so that you don't ever miss a concert. I'm looking for developers and designers to implement the site, and business-savvy people who can help turn my idea profitable. I'm Owen and my idea is StageDrive."

Each pitch name was written in marker across the top of a giant 3M stickynote and placed on the wall. We wrote a summary of the idea underneath and some more information about what we would need for implementation. Then, we went around the room and interviewed people whose ideas we liked best to learn more about their needs and plans. If we ultimately liked their idea, we could apply one of our three stickers to their poster to vote for their project.

I looked for a few projects that I thought were worth considering. There was one, Family Time, that was a social network for families that feel they don't spend enough time together. Another was a system for local bands to gain followings and exposure like for bigger bands. There were so many interesting projects. One was by a woman named Anittah who wanted to build a system to help educate teenage girls, who are one of the highet risk groups to get into trouble with it, about credit - Credit Cardio.

In fact, I was pretty set on joining with Anittah by the end of this round of the weekend, so much so that I stood nearby waiting while she explained some of her thoughts to an older guy who had asked some simple question. What happened next happened so quickly, I'm not sure how it did. When the old guy moved on, this pair of developers showed up suddenly, shoving their cards into Anittah's hand. Apparently, they had some platform they work on and wanted to apply it to her project. They assured her they could build it with very minimal effort. A deal was struck, and after they left, I was dumbfounded. Had I simply moved too slow? Surely I could get in on this project, still. I talked with Anittah, who seemed optimistic, but not technically savvy enough to know that a custom platform would only be useful to the people who were familiar with it -- she would basically be reliant on these two guys for the whole thing unless their platform was simple or widely-used enough to be adopted by other people that would join her team. Sadly, not only did she not understand this, but the two developer guys seemed completely unwilling to work with another developer, or at least, I didn't have the inclination to convince them otherwise.

I suppose the lesson here isn't just for me ("Move faster!"), but also for entrepreneurs without technical knowledge. You really have to watch your team and hear what they tell you, because this one detail excluded others from participating. I think that some other developer might have joined her team in the end, but still... Anyway, I was bitter.

So I went off in search of another team. I returned to Adelaide, who was someone that I met while waiting in the auditorium, to see how she was doing. Her pitch was for a travel site that helped timid travelers commit to all of those fun off-beat adventures you're always seeing on the travel channel. People like the idea of travel, but have certain fears that make traveling nerve-wracking, and her idea was to produce a site that would mitigate that fear.

Well, I like travel, for sure. And Adi and her husband, James, were very easy to get along with, as were the others who had joined her team. Kim, the only other developer to sign up with our team, was a great fit for me, being very competent at the front-end work, while I could concentrate on the back. Kim's boyfriend, Jeff, was well-traveled and charismatic. And Luke rounded out the team with his Wharton credentials and travel experience. Altogether, the makings of a good work unit.

We chatted a little about the project, then retired to a gastropub to discuss beer, our travel experience, and what we were going to eat for dinner. By the time 12:30 rolled around, we had a pretty cohesive unit.

Saturday, we spent putting the project together. It's kind of a blur, even as it happened only a few days ago, just because we did so much. We acquired hosting. We chose version control, platform. We all decided what the site was going to offer and started to assemble content. It actually started to come together.

One weird thing was that we kind of seemed to be expected to just go. The organizers suggested that we appoint roles, and that was about it. There were coaches roaming the floor, available to help, but more often I found their intrusion annoying. Rather than asking helpful, directed questions based on what we were doing, or offering suggestions about how to go about any of the phases of building a successful presentation, they always seemed to drop in in the middle of an important team discussion with some random useless question. I think we really could have made better use of the coaches, making sure they were helping with the things we were actually doing and pointing us in the right direction for the next action. And yet, it's surprising to me with what little help we got or asked for that we made anything viable for the end presentations.

By the time the organizers rolled around at 10pm Saturday night to tell us the open bar was open, I was pretty deep into coding my part of the project. For the first time in a long time, I'd been given something to start from scratch that was interesting and actually starting to get somewhere, fueled by a small team of people who were also interested in getting something useful done. There's really nothing quite like that experience. Something that would be very attractive to me now is continuing to work like that, in a small team, in person, with competent, intelligent people that I enjoy the company of, for as many consecutive 14-hour days as it takes to get it done or go insane trying. But we all took a trip over to the bar, just realizing that we needed a break.

The University of the Arts building that we used closed at 11:30pm, so we called it a night shortly after the one beer from the open bar. I opened my dev environment at the hotel and coded until 1:30 or so, but after the long day, it felt good to finally pass out.

Sunday morning, things really started to come together with what we were building. The database hooked up, the content from the team was going in, Facebook logins worked, the design Kim put together with virtually no resources was an amazing feat - one that I think most of the other teams didn't come close to. Sure, there were glitches. Production deployment was a little sketchy. I made some mistakes. It happens, but in the time-limited environment it was frustrating. But in the end, we had our site, Off-Track Online.

Adi and Jeff were putting together a presentation for the culmination of our work. They used Prezi, which is a kind of Flash-based presentation system. In combination with the compass rose we used for the logo, it turned out pretty snazzy.

I admit I was a bit worried about some things. Our team did tend to split a bit along technical/non-technical lines. I didn't really have a good idea of what was going on with the presentation, and we didn't show a lot of what we had going on with the site. As a result, I think we could have showcased our work a little more, because we had more actually done than a lot of the other teams. I never heard the presentation myself before it was presented, and I think we probably could have gone through a rehearsal to make sure everything was clean and on-point. In the end, all of the ideas were great, but I felt they could have been a bit more focused. Still, Jeff and Adi did a great job presenting the product to the crowd, and represented us well.

So around 5pm we all headed to the auditorium for the presentations by the 18 teams. Each team got 5 minutes to present, and 5 minutes for potential questions, and that was it. Then the judges would convene and render their decisions.

The teams did a really good job presenting what they spent the weekend building. My favorites included Truxi, which is a service that pairs people who are moving with people who own trucks so that they can rent the time. The presenter knew the idea very well, had shown that there was a market for the service, showed that there was money to be made doing it, showed projections of the money coming in that were realistic based on surveyed demand... I thought it was impressive.

Credit Cardio was also a pretty good presentation, and Anittah was very energetic. The presentation had a different focus from when she described it in the pitch, seeming to try to cover a broarder market. The site they constructed was clean, but a little sparse, and the functionality seems to be supplied from a bunch of odd sources, rather than being something that was built specific to purpose. In the end, I'm not sure what those original guys that "ran me off" contributed.

Seed Invest, whose initiator was one of the people I spoke to before the event even began, was also in the top three, offering Kickstarter-like services but for equity, based on the recent provisions allowing this in the jobs act. The site is pretty, but has very little active functionality.

One of the projects closest to our milieu was Itinerate, which is a site that helps you build detailed itineraries for your travels. It's not the same as our idea, but meshes pretty well. Actually, combining both of these sites with something that lets you book trips, organize your plans ala TripIt, and then diary and publish your travels would be a fantastic, full-service application.

I don't mean to say that any of the projects were sub-standard in development. Ours could even use some polish. I just feel like, in comparison to the other teams, we accomplished a lot more real, custom work that could be re-used if we continue to move the project forward. Most of what we saw from other teams in terms of what they had built seemed to be pretty mock-ups, whereas ours was actually at least "something".

I thought that we probably could have done a better job with organizing our presentation at the end, and I think we only suffered because none of us knew as well what to expect or deliver. Now having seen several excellent Startup Weekend presentations, I can imagine how we could improve ours. It would once again include the elements of an essential pitch - problem and solution - but also focus specifically and clearly on things I know we had answers to:

  • Demonstrating that the idea is one that people will pay for and that the market does exist.
  • Clearly outline how the project would earn money.
  • Show the level of completeness of the project in a true live demo.
  • Explain how well-assembled the team is for the job, both in terms of expertise and ability to coordinate

Many of the teams did really well in one or two of these areas, but not in all of them. Perhaps that is why Yagglo won first place with the judges. Their site doesn't show the thing they built, and neither does their slick YouTube video. Having seen the in-development app working first hand, I can tell you that while it does do some of the stuff in the video, it's glitchy, and nowhere near as polished. The judges had to have been impressed with a very-well-crafted slideshow, along with a reasonable coverage of the criteria (above) required to have a winning presentation.

After the three days of the event, I wasn't enthusiastic to go out to the open bar and DJ, but I was pretty hungry for some food other than what they'd been serving at the venue, so I went out with the Off-Track Online team to Fadó. We hung around with the other participants, chatting about our success and potential future plans before I took the long drive back home.

In all, the event was a success. For me personally, it was a great learning experience. I learned a lot about initiating startups and working with other people. I met a ton of cool folks, especially my team of "nomads". There are other lessons that are personal and harder to articulate as well. But all good.

One thing to consider after one of these events is whether to continue the partnership that produced the results over the weekend. Truly, I was so focused on just getting through to the end of Sunday night, I wasn't even considering what could happen afterwards. I think that if we can focus the project into something that makes money, it would certainly be worthwhile to continue development for it.

As far as future Startup Weekends go, I'd love to try again. I'd like to get a good idea of my own. I'd like to pitch it and hobnob with the other attendees and try to get a team on board. And while my skillset tends more obviously toward development, I think I'd like to get a bit more involved on the business and presentation side in the next round, just to see how far I can take it. After all, the reason I did this was to learn how to apply this breadth of knowledge to my own startup ideas.

But after all that, I want to thank my team once more, who were fantastic, accepting, talented, experienced, fun folks who I'd work with again anytime.

Write Your Own Adventure ProgramsOn a family trip to the Computer Museum in Boston I convinced my parents to buy me a copy of Write Your Own Adventure Programs for Your Microcomputer, since I was an Infocom junkie and had been writing my own "adventure programs" for some time already. I think this was my first technical book, and it was the first technical book that I met with disappointment.

I'm not sure how I picked up programming prior to books. Probably a combination of experimentation and entering programs from magazines. Unlike the other few kids I knew who also had computers, I didn't spend a lot of time playing games. I mostly wrote code. Technical manuals that helped with this were rare.

There are very few good beginner books that are useful to have around after you've learned the basics. I have a couple of books that I keep around and refer to now and then (on very rare occasion anymore) for nuances that I've not committed to memory. Actually, scanning my bookshelf for them now, I see that Berta has run off with them. But even these aren't books for beginners.

The "For Dummies" series has always grated on me, and probably anyone who considers themselves intelligent enough to start learning something from scratch. I find that these books lean the opposite way of most other beginner books, in that they have too much "you can do it" prose and fancy icons, and not enough meat. Most beginner books have too much detail or assume too much foreknowledge, and don't contain enough explanation or encouragement. I find this particularly so in every Ruby book I've encountered, which seem to all begin at a point where Ruby syntax already makes sense. Here's a clue -- It doesn't.

Beyond the beginner book, I often find the organization of technical books perplexing. Sometimes you just want a technical reference. The SitePoint Ultimate HTML Reference is a one of these. They've tried to organize this book into logical groups. Sometimes this is useful, but more often than this, I just want to look up a single tag and can't find it quickly because it's in some strange section I hadn't imagined. I think this grouping is unnecessary in a reference. Alphabetic is good enough. Adding some "see also" references to the items if you need a cross-reference to related tags would be a better solution than these groupings.

Technical books also go stale very quickly. Even my copy of the above HTML reference is already out of date. It doesn't include the common HTML5-specific tags like section and header. And as the HTML5 standards change (like any technical topic does - very quickly), the book becomes more and more stale. Offering online supplements to the books keeps the information that the "book" offers more fresh, but then, is that really the book? If I wanted an online reference, and let's face it -- there are plenty of great, free online HTML5 references, wouldn't I choose one of those instead of paying for a hardcover book?

The main issue I have with technical books is that their digital incarnations are insufficient. We've somehow failed to develop a useful transition from paper to digital that includes a useful way to integrate the two mediums. The online versions tend also to be very poorly formatted for use when at the terminal. I actually despise using the Kindle version of most technical books because they're not anywhere near as handy as flipping paper pages. The mere thought that the paper version works better indicates to me that something is wrong with the UX of the digital version.

Not as a perfect example to fix all of my issues, but as an example of what would be useful, consider a book about HTML5. Imagine a thin book with the basic properties of HTML5 tags and usages. The book would only have the tags, display the basic tag attributes and common values, and most-indexed information. Each tag entry would contain a reference that opens a more detailed page from the web, that can interact with the book (by providing physical page number references, for example).

With the current state of on-demand printing, it might even be possible to print the current state of the HTML5 standard, on-demand for each copy ordered. Your book would have a serial number correlating to the book's web site that would indicate what changes your book contains that the web site would need to account for. If your book became sufficiently stale, you could order a new, current copy. An indicator on the site could show how stale (by percent?) your book had become in relation to the evolving standard and the online content. This would be a useful indicator of whether a new edition of the book would be worthwhile to purchase, although I'm not sure there's a great benefit of this to publishers who simply want to sell new editions every year with a few pages swapped out.

I would like to see technical books completely rethought. There's a newer trend in these days of on-demand printing for small web design shops to sell 64-page books for $30+ on single topics. That's interesting, but certainly not as nice as getting the same high-quality content in an updated volume on a regular basis. I wonder what thoughts others might have about how to make technical publications more useful.