Authentication System Changed

I was surprised that my planned changed to authentication stirred up some controversy. The basic issue is that Google IDs, which I'm using for authentication, only allow you to use one Google ID at a time. That means that if I force you to switch to a different Google ID (because I need you to prove your email address), that might sign you out on other sites. Not all sites work that way. For example, the way I've done authentication on Puzzazz , you will not be automatically signed out the next time you visit. But that's not the way most sites do it.

In the end, after weighing the options, I decided to go ahead with my plan to switch to only keeping email addresses. Of the various other solutions, all of the good ones are a superset of what I was planning to do, or can easily be built from it. The other solutions are more complicated or more problematic, or keep the problems I was trying to avoid. So, I did it and it's working now, at least for projects. Now I can go back to dealing with the issues that inspired this change.

I forgot to post last night (too many things going on), but the chart still includes yesterday as a working day.

A Day on Puzzazz

I spent today working on Puzzazz instead of Groupthink, cleaning a few things up and changing the book recommendations completely. Now, instead of alternating an Amazon widget (which was just plain ugly) with Google ads, it now shows one book or product per day and there's a dedicated recommendations page showing the recommendations from the last six days. I've also added some text to make it clear that these aren't books that were randomly selected by Amazon or some program. Check it out at www.puzzazz.com.

I also had an extra reason to hold off on Groupthink today. A bunch of feedback on my planned authentication & authorization changes to Groupthink made me think I might want to let the idea bake for another day before finishing it.

One Down, One Up

I finished up one client task today but I realized I have an extra Permissions task. I've decided to make a slight architectural change to the way I've been handling users. I haven't figured it all out, but a discussion late this afternoon with Damon Cortesi (who had stopped by StartPad and just happened to be there when I wanted to think about it) helped solidify my thoughts that it was a change I ought to make -- and the time to do it is now because it'll be more painful later.

When you give permissions to someone else in Groupthink Projects, you provide their email address. A lot of the time, it's an email address that the system's never seen before, so I cannot associate the email address with an actual user. But, later, when the person signs in, I can. And that's exactly what I have been doing, partially because of advice from Google -- they advise that apps shouldn't store users' email addresses because they might change (although there appears to be no current way that they could). So, as soon as a I know the user for the email address, I switch to referencing the user. But, this means that, in all my permission code, I have to constantly check if a permitted person is a user or an email address. That's a pain and leads to problems, some of which I was dealing with.

So, I've decided, even though it's late, to change this and switch to only using email addresses. I'm also considering an additional change, which would also go against the normal way of doing things on Google App Engine. I'm less sure about this change, but it would allow me to simplify the logic in dealing with item-level permissions. The tradeoff is larger data storage, and a slight redundancy in one place, but I think that's an ok tradeoff to make. I'll ruminate on it this weekend.

At the STS talk on tuesday, Rajiv Goel asked me when I was going to launch and I said I didn't know yet. The correct answer would have been to say "when I can guarantee I won't lose your data." That's not the only criteria, but it's the most inportant one. Although this change needn't cause data loss, it woudl be a good thing if I'm confident I won't need any more changes like it when I launch.

More UX Office Hours Takeaways

I had my once-a-month UX Office Hours at StartPad again today. No one showed up for the first hour, and then I was busy straight through and actually ran a bit over. For various reasons, I really feel I can't talk provide any details about the people who stopped by. I can, however, provide a few takeaways which might be useful to others.

• If you can solve a problem for internal users first, and then focus on external users, you are, in a way, lucky. You're not lucky because you have the problem in-house. But you are lucky because you have real people who will be using the software before outsiders and, although it sounds like cheating, you can do less for your in-house people because they work for you. For example, if things are ugly, just tell them to ignore it -- you can't exactly say that to real customers.
  
• If you have a big problem you want to tackle, and you can figure out what the biggest pain points are, focus on them first. Don't focus on the easiest problems -- focus on what gives you the most bang for your development buck.
  
• Don't clean up the little stuff (the look, the graphics, the CSS, etc.) when you're not sure what you're cleaning up should exist in the first place. Yeah, it'll look a lot better, but you'll have wasted time if you end up tossing it.
• If you have a non-technological competitor (as Groupthink Projects has), you really need to make sure what you're building is very easy to use. You want people walking away thinking about how much faster they accomplished their goal than they would have without your product, even if it's not true. Perception is reality.
  
• Your competitors may surprise you. I mentioned in my STS talk that Microsoft Word is a competitor to a database system. Similarly, Google would be a competitor to a price-matching service (and about a hundred other products).
• One way to get customers to stick is to really focus on those things that make you unique, that your competitors don't offer (where competitors also equals Microsoft and Google). Consider making the things that are unique about your product so pervasive that your users come to expect them there, all the time. Then, it won't feel right to them when they try to use your competitors.
  

Tomorrow, I'll discuss some of the things from my talk at STS.

Only half a day of real work today (and a few distractions there), so flat once again. I'll admit, a lot of it's a grind right now.

Screenshots!

At last nights talk, I showed Groupthink for the first time publicly. The first half of the talk was a discussion of mistakes I've made in the past, mistakes I'm making now, and a few things I'm doing right. That was followed by some screen snapshots and a brief live demo (which, as noted in yesterday's blog post, had a glitch because of the lack of a network connection).

Here are ths screenshots I showed:

Basic Screen, showing an open project

 

Same project, with some items checked off

Options for a project

Project-level sharing options (you can also share individual items)

I'll write more details in the future, but if you can't wait, a video of the talk is available already.

And today's status, back to making forward progress, with one client task taken care of:

The Demo Gods

Tonight, I gave the first public demo of Groupthink Projects at a Seattle Tech Startups meeting, along with three other startup companies. Overall, it went pretty well. The first half of my talk was about mistakes I've made and what I'm learning from them, and the second half was about Groupthink Projects itself, featuring a few screenshots that I took earlier today and ending with a live demo. And, of course, as seems to happen in all live demos, something went wrong.

I had planned to show two things in the live demo -- asynchronous updating when you make multiple changes in quick succession, and the first-time experience for new users.

The first thing I was showing, asynchronous updating, went fine. But, the point I was trying to make -- that you can keep working while it's updating the server -- was considerably less obvious when I wasn't running my server in debug mode, which is easily ten times slower. So, the busy icons I was trying to point out appeared and disappeared so quickly they were hard to spot. Hopefully, everybody got the point -- no delays.

The second thing I was showing was the first-time experience. When a new user visits Groupthink Projects, they immediately get a new project -- no questions, no sign up, no nothing. They can just start immediately. To demonstrate this, I opened a new Incognito window in Google Chrome -- this ensures that I don't have any cookies and the browser will look like a completely new user to my server. Then, I opened the site and I got a new project. So far, so good. Unfortunately, when I tried to click to type, nothing happened. I refreshed, same thing. So, I moved on, and signed in (which is all you have to do to register) and got the appropriate "Welcome" message, with the project now being owned by my new user. But, I still couldn't make any changes to the project.

Someone in the audience joked that I had forgotten "Pray to the demo gods" on my to do list for the presentation, which I had shown earlier. I didn't have a better explanation.

Later, while someone else was presenting, I went to look at what was going on. It was amazingly simple. Rather than loading jQuery from my own server, I'm getting it from Google Code. It's faster and it saves bandwidth. Unfortunately, I didn't have a net connection, so everything from my local server loaded, but jQuery didn't. No jQuery means no client functionality. The first project I showed worked fine because I had opened that window while I still had a net connection. I'll be fixing the code tomorrow to load jQuery from the local server when running off the development server.

Still flatline on tasks today. Some of the bugs I fixed earlier in the day were progress for some of them, but, to be fair, I didn't really complete any tasks.

Games And Bugs

Flat line on progress today for two reasons:

First, I had been procrastinating sending out a Puzzazz newsletter and I finally sent it today. Unfortunately, doing that for the first time, combined with some other issues, took up half a day. But, as part of that, I finally got around to officially announcing that I'm selling copies of my game WIM, the every which way word game. Here's a picture of a game in progress and you can find more information at http://www.puzzazz.com/wim.

Second, I'm giving a 10-minute presentation about and demo of Groupthink tomorrow night at Seattle Tech Startups (7PM, at The Douglas Forum at the U-W Executive Education Center) and I'm not ready yet. Bugs to fix and a presentation to prepare (and prepare for). That took priority over closing down specific tasks.

That means that today's chart isn't particularly interesting, but here it is anyway for completeness.

I Want You To Win

At Microsoft, the structure of performance reviews is a zero-sum game. If you and I are in the same group, that means that in order for me to win, you have to lose. In fact, if I'm your boss or you're my boss, we're competing with each other. If I give you a better review, it may mean that my review score goes down, and vice versa. I've heard that this has changed somewhat since I left, but I've also heard that the overall attitude hasn't:

In order for me to win, you have to lose.

Unfortunately, I've seen this same attitude migrate outside of Microsoft in some (but not all) companies founded by ex-Microsoft people. But, when your whole company only has five people, you're all in the same boat. You're all going to sink or swim together -- you can't afford to compete with each other.

The really great news is that I've seen a lot of the opposite attitude in the Seattle startup community, with people not just collaborating inside companies, but helping other people and companies. The discussions on the Seattle Tech Startups mailing list are a great example (and, in fact, this post was inspired by a recent discussion).

Case in point for me. I had a meeting today with someone with a great product. I can't tell you what the product is, but I think it's really neat. I would use it myself. Meanwhile, one of the things that I've been looking for is a CEO for Groupthink -- I need a business partner who knows all the stuff that I don't. It turns out that the guy at lunch has the exact same need. After my meeting, I sent him a bunch of my contacts, despite the fact that we're basically in competition. But, the fact is, if I've got a great CEO candidate who turns out to be a better fit for somebody else, who am I helping by keeping that contact to myself? Not the other company, who would miss out on the candidate. Not the candidate, who misses out on an opportunity that fits better. And not me, either, if I end up with a CEO who would be happier elsewhere. So, sure, I'll give away my best contacts. In the end, I lose nothing. And maybe I'll get a contact back that I wouldn't have had otherwise. And who knows what else an come from a mutually supportive relationship?

We can both win.

Project update for today: whittling away, but the curve isn't looking quite as nice as it did a week ago. I think I'm going to take the weekend off, spend time with my family, and try not to go crazy.

Privacy Can Be Hard

I originally had planned to write something different today, but I'm going to save that topic for a possible future blog post and, instead, point you to somebody else's blog. Scott Ruthfield, a friend of mine who I worked with at Microsoft (and who's also a member of my Microsoft Puzzle Hunt team) just wrote an excellent blog post about privacy issues with a new Amazon feature.

Amazon’s iPhone mobile app and privacy

"And the idea of Amazon Remembers - a place for you to take photos and have them stored online - that’s neat, though obviously overlapping with dozens of other photo storage services. It also offers product identification - take a picture of something and have people tell you what it is.

Remembers, though, breaks the social contract: it makes pictures that reasonable users might assume will be private, and makes them public."

Read entire post

Meanwhile, today's New York Times has an article about How YouTube Broadcasts Your Tastes in Videos. All this just goes to show that privacy can be hard, even for big companies.

At the moment, Groupthink Projects handles privacy in a very simple way -- your data is shared only with those people that you choose share it with. That makes it easy for now, but it seems that constant vigilance is a good idea.

In terms of progress, because I had three meetings today, plus the MITEF presentation tonight, I didn't get the last permissions & security task finished. It might take more than a day anyway. But, I picked the easiest client item and did that, so at least I'd be making forward progress.

Why Business Cards

A few days, Tony Wright of RescueTime and I were chatting and the topic turned to business cards. Tony made the excellent argument that entrepreneurs, in general, should always concentrate on whatever things they have on their list that will make the biggest difference in their business. And, business cards are never on that list.

At the time, I said that I not only had business cards, but that I had probably given out more cards in the last few months than in the previous thirty years, combined. Tony asked what percentage of those cards had resulted in a follow-up and I admitted the number was small. But, tonight, I sent an email to somebody whose email address I would not have had if he hadn't handed me his business card. I know that most of the cards I hand out end up in huge piles of cards on the recipients' desks (and, yes, I have such a pile myself). But I also know that, if they need to reach me, they can pull my card out. And I do that myself maybe a dozen times a year.

Right now, because I'm spending a lot of time networking, I'm constantly giving people my contact information and I need to be able to give it out easily. Business cards may be old fashioned and they're not particularly efficient in many ways, but they're still one of the best and fastest ways to exchange information. We can't all exchange contact information via QR Codes on our Google G1 phones.

I'm not saying that you should go off and print business cards (or t-shirts) right away. But, when you're thinking about those things that will make the biggest differences in your business, look at the whole picture, and don't make the decision based on what might make the biggest difference in somebody else's business -- I need business cards and Tony probably doesn't.

On Groupthink Projects, I finished one task today, leaving me one permissions/security task, one large scale test I have to run, and eight client tasks. Obviously not all tasks have turned out to be the same size, but I'm not going to start charting subtasks at this point.

P.S. Even though it seems like things are taking forever right now, RescueTime seems to think I'm productive. I have a productivity rating of 1.37 (1.47 this week), whereas the average user is 0.58 (0.61 this week). That just means that most of the time I'm trying to work, I'm actually working, not hanging out on Woot.com.

A Potentially Nasty Bug

I had a productive day today, but it wasn't on Groupthink. Got a little bit of work in on one of the Permissions tasks and hopefully I'll wrap it up tomorrow.

But, I did discover and fix what could have been a really nasty bug to track down. Simply put, because multiple people can edit the permissions of a project, it's possible for two people to try to make a permissions change at the exact same instant. And I was not doing the update in a transaction. But, because of the way Google App Engine projects work, using a transaction has a downside -- it doesn't just lock out changes to permissions, it locks out changes to the entire project. So, I changed the code to use a transaction, but only in the case where the project already has more than one owner. I'm also going to look into moving the permissions into a separate table, so that the transaction doesn't lock the whole project, but that's a change that can wait until post-launch. The tradeoff is how often it happens versus how much it slows the system down when it's not happening.

Giving Back

When I was at Microsoft, I had the wonderful opportunity to be loaned out to United Way for four months, as a United Way Loaned Executive. I spent four months out in the community, helping to raise money to help those in need. It was a wonderful and humbling experience, and helped affirm in my mind just how lucky I am, to be able to make money doing things that I love to do. So, if you're looking for extra year-end tax deductions, think about giving back to the community, to help those who are less fortunate.

But, this post is really about giving back in a different way. These days, giving back in the software community is known as "open source." If you're Richard Stallman, or a fan of his, open source is all about moral imperative -- it's unethical for software not to be open. For that matter, Stallman believes that web services like Groupthink are "worse than stupidity."

I look at things rather differently. Open source is about giving back -- paying it forward with code. Over the years, I have benefited greatly from the advice and wisdom of other members of the community. I don't know where I'd be today if I hadn't gotten help from experienced programmers when I was hanging out at the University of Kansas Comp Center, trying to learn Fortran and GCOS assembler. I've learned a lot since those early days, but I still get plenty of advice from others (these days, most of it is about Groupthink). But, today, I'm more often on the giving end, from casual advice to blogging to User Experience Office Hours at StartPad. And it feels good to help people.

Today, I'm releasing my very first piece of open source software. When I started Groupthink, I decided that I wanted to be able to give back some pieces of software. The first piece is a small piece -- a little bit of Python code to interface with Twitter that I used in Puzzazz. The impetus to release this particular piece of code now was that someone asked for it. So, I figured I might as well go all the way. A couple of things to note: it is ok to use it in commercial software, and it is ok to learn from it and write your own code. Check it out at http://www.royleban.com/opensource/. After Groupthink launches, I'll release a few more items, at least one of which is pretty large.

In work today, I made good progress and am almost ready to tackle the client code.