4 Days: Groupthink Has A Logo

I've been thinking that I would probably launch Groupthink without a logo. On the plane back from Michigan on Monday, I drew up a lot of different versions of "Groupthink" and "Groupthink Projects." I wasn't happy with any of them. For one thing, there are a lot of logos that have a stylized "G" or "g" and I didn't feel I could do something fresh there, as I did with the Puzzazz logo.

But, in the back of my mind, an idea started taking shape and that was to design something around a checkmark. At StartPad today, I asked Mike Koss and Zach Zelinski for their thoughts and Mike independently suggested the idea of using a checkmark. I sketched a few ideas on the whiteboard and Mike drew a few things in his notebook. I'd been leaning toward a checkmark by itself rather than with a box, so as to make it look less like an option, but it seemed so plain. And it's well-covered ground as well. Then I spotted a book on a bookshelf with text in a word balloon and I thought of the idea of combining the two. The result, after a bit of playing tonight, is a decent logo:

And now back to coding. I still have a lot to do.

5 Days: Why I'm Not Planning A Beta

A couple of years ago, I worked with a guy who had a mantra of "Never Lose Data." He argued that, basically, every single keystroke, every single piece of user-entered, user-created information should be preserved, forever. Infinite undo forever. In some cases, I think he's right. In some other cases, I think he goes too far.

But, he's absolutely correct when it comes to the underlying concept: user data should never be lost.

When web services are launched in "Beta," it's frequently an excuse. It's an excuse for a lousy experience. It's an excuse for bugs and lack of reliability. It's an excuse to point to when users have their data lost. I even know of beta sites where tossing user data was part of the plan, which I think is, basically, unforgivable. Who wants to use a service where there's no guarantee that your data will actually stick around?

I can't absolutely guarantee Groupthink's reliability, but I'm trying hard. And, I'm taking steps to ensure that you don't lose data in the event of an outage or a bug in the system. Today, I worked on server data handling. Not only did I spend a lot of time testing the code to make sure it was correct, but I also wrote explicit code to aid recovery in the event of problems. I hope the code is irrelevant (and it might well be a royal pain for me if I have problems), but the time to do the work is now, before it's too late.

So, whenever I launch Groupthink, I'm not going to call it a Beta. It might be limited, it might even have problems, but if you're going to entrust my service with your data, I take the responsibility seriously.

6 Days: Making It Right First

So, what's the right answer to yesterday's question? Do I push out my launch date, do I cut things, or what? This is one of the rare times I've received clearly conflicting advice. The advice splits along the following lines:

• Stick with your date, launch with what you have.
  
• Way too much software ships before it's ready. Don't make that mistake.
  

Gee, that helps.

Right now, I'm just below the threshold of "it's actually useful" and I feel like I'm going to get there any minute. Once I get there, I think it'll be downhill. Kernighan and Plauger famously wrote:

Make it right before you make it fast. Make it clear before you make it faster.

That's the biggest piece of advice, modified slightly, that I'm following right now. I'm trying to make it right and clear before I make it fast, before I optimize my code, before I make it pretty. (Of course, making software pretty wasn't much of an issue in the '70s, so that's my addition.) There's a lot that I want to do that isn't absolutely essential to the launch and I'm trying real hard to focus on just the essential stuff. Making it right means it works, it does what it's supposed to do, and users won't lose their data.

So, despite the rather large speed bump that I just went over, I've resumed my countdown toward November 3rd, but I don't know for sure if I'll be able to launch then or not. I'm certainly going to try.

?? Days: Timeframes

If this is Tuesday, it must be ...

Actually, I'm not sure what day today is. I got back from Michigan last night, where I helped move my father-in-law into his new home, an Alzheimer's care facility. It was hard and difficult (and exhausting). Sad to say, a lot of people who move their loved ones into facilities like this do little more than move them there. We did the opposite, moving his own furniture, his own art, his own books, his own bedspread. The "apartment," as we call it, looks like a miniature version of his house. The number of things that had to happen to pull this off in the short timeframe available was daunting and it absolutely had to be on time. It took all of my project management skills, not to mention design and box hauling skills, to pull it off, and we did. I completed my last trip to the facility to finish things up two hours before we took him there.

Now that I'm back, I don't know if I can pull off shipping Groupthink on time. I knew I'd be busy on the trip, but I thought that I would get maybe five hours a day to work. The reality was that I got about five hours during the entire trip, entirely on Sunday and Monday. And that's quite a step down from the typical ten to twelve hours a day I've been working. So, on my list of tasks for today is to evaluate whether I can stick with my original schedule of launching on November 3rd or if I have to push it back a bit. And do I need to cut anything else? One complication is that I am heading out to the Hackers Conference on November 7th, so I don't have a lot of flexibility in slipping my date.

You might ask, why say something now? Why not just wait until I know for sure? Well, first of all, I believe in transparency. Through the transparency, I hope to be able to help others doing similar things, and I also receive advice from people. If I limit my disclosure, both are significantly less useful.

12 Days: Cut Early

When I built Puzzazz, I built a mobile version of it, with pages specially designed for small screens. I also let you switch which version you get if you prefer the desktop version on your cell phone. Building the mobile version of Puzzazz took me, literally, a few hours. A fair number of users visit Puzzazz from their mobile phones,when they have a minute or two and decide to solve today's puzzle.

For Groupthink, I think mobile usage will be even more important. However, because Groupthink relies heavily on client-side code in JavaScript and many cell phones don't support JavaScript, supporting mobile browsers properly is a lot more work. Among other things, the mobile version requires more (and different) server support.

Today, I decided to cut the mobile version for my first launch. It's a cut that I hate to make, but it's the right time to make it. So far, I have written almost no code for the mobile version and none of the code that I have written is a problem -- it can all remain unchanged. It's one line of code to cut the mobile version, but, by cutting it, there's a bunch of new code that I don't have to write yet. And, the desktop version will still work on many mobile phones, so I'm not abandoning those users. In the meantime, I'll continue to note places where I have to do a mobile-specific branch and I may even write some of the code, but the big piece of work -- the mobile-only work -- I will defer.

Far too often, particularly at large software companies, cuts are made helter skelter. They have 5,000 features they want in the application. That's a problem in the first place -- they're looking at feature lists instead of the big picture. They pare that list down to "only" 500 features, which they start to implement. A few months in, they realize they're behind, so they cut some features that are half-implemented. They repeat this process a few more times. By the time, they're done, they have 400 partially-implemented features that they've tossed and a 100 actual features they plan to ship. Now, if they had back all the time from those 400 killed features -- if they would only cut features before they start implementing them -- they could have made the features they actually did ship better.

I really want to launch on time and I know that time is tight. I'm not positive that I actually need to make the cut, but I'm being conservative and I'd rather cut it now than cut it later. By cutting it now, I'm freeing up time to finish everything else. I can use the remaining time that I have more wisely and I don't feel too bad about the few hours that I've spent on it so far. And, it's a clean cut, with no repercussions in the code. And, just to be clear, Groupthink will absolutely have a mobile version -- it just won't happen as soon as I'd like.

Family First

Speaking of the time that I have, I'm going to be absent from this blog for a few days because of a family obligation. Tonight, I'm flying to Michigan to help move my father-in-law to an Alzheimer's care facility. It's sad that we have to do it, but the time has come. Originally, we had thought that my wife could do it on her own and I would stay here and work. But it became clear in the last few weeks that she couldn't do it without me. And, even when I'm in the midst of a crazy 30-day project, family has to come first. I'm taking my laptop with me and I will try to work as much as possible. Unfortunately, I probably won't have an internet connection (and the 15" screen is no match for the 24" one I normally use).

I get back on Monday, but may not blog until Tuesday.

13 Days: Self Hosting And Dogfood

Computer programs are written using compilers (and interpreters), which translate high-level languages into machine language, either directly or indirectly. But what do you write the compiler in? For almost fifty years, many compilers have been written in the language they compile. Although that sounds like a contradiction, there are many ways to accomplish it, usually involving using an earlier version of the compiler not written in the language to compile and then bootstrapping forward, like the robot of many a science fiction story that can build more robots. A compiler that can compile itself is referred to as a self hosted compiler. Self hosting is a good thing. It helps ensure that the people working on the compiler know as soon as possible when there are problems.

A related term that is in more common use is dog food, as in the phrase "eating one's own dog food." Although originally used only at Microsoft, the term is now widespread throughout the industry to refer to a company or team using its own products to do their work. Like self hosting, when a team uses its own products, they ensure that they discover problems first, before users do. Sometimes, its painfully obvious when a product hasn't been used by the people who created it, because it has flaws so obvious that nobody could have actually used it without discovering them.

Groupthink reached a major milestone today, without even fireworks to mark the occasion. The first piece of real data -- part of my task list for the project -- is now live in Groupthink Projects. As a project, Groupthink is on the way to being self hosted and I am starting to eat my own dog food. It's good news, but it also makes me acutely aware of just how much work I have left to do.

14 Days: Compromising Perfectionism

I'm a perfectionist. Maybe you wouldn't know it if you looked at the mess on my desk in my home office. And, I'll admit I'm not a perfectionist at everything. But, on many things, from software development and user experience to puzzles and photography and cooking, I can't help but want perfection. When I wrote about commenting code earlier, I forgot to mention that my comments are also grammatically correct and properly formatted. My variables all have good names and, when I realize I've misnamed something, I want to fix it right then (I did that twice today). I hate putting off fixing things when I know they're broken.

I've worked with plenty of people who were the exact opposite -- so driven to deliver that they would take any excuse to avoid getting things right. That just drives me crazy. Even though I'm a perfectionist, I like the middle ground -- I like the compromises that come out when you have both the perfectionists and deadline-driven folks in the same room. To deliver the best product with limited resources in limited time, compromising is key.

Unfortunately, Groupthink is a team of one and it's hard to compromise with yourself. This is one of the times that I wish I had a team instead of just me.

Short post today. I should have some good news tomorrow.

15 Days: Fictional Technologies

I've mentioned that Groupthink uses Ajax and that I built my first web service using it in 1997. But, despite the fact that the X in Ajax stands for XML, I'm not using it now and I didn't use it then (back then, JSON didn't exist yet, so my format was proprietary).

You might think this is strange -- how can I say that I was using Ajax when I'm not using XML. And, how can I say I was using Ajax before the term even existed? Well, in a large sense, Ajax doesn't really exist -- just like Web 2.0 and, before that, DHTML. They're all fiction. Ajax represents some common techniques for building dynamic applications in a web browser. Web 2.0 has come to represent a certain style of dynamic applications. DHTML, well, that's just writing programs in a browser. In a way, it's all like art -- people know it when they see it.

But, in this case people actually means developers. Real people -- real users -- could care less about any of this. They just want their problems solved. They don't want pain. And they don't care about the technology, especially technology that's more of a branding exercise than anything else. I picked the technologies I'm using because I think that they are my best best for solving problems and eliminating pain points, not because I want to tout them on the web site. I'm trying to satisfy people, not just other developers.

All that said, today, I was able to run my first real Ajax queries -- whatever you want to call them.

16 Days: Working in Groups

Today's Six Hour Startup was near my house on the Microsoft campus today. So, despite the fact that I'm pretty busy, I stopped over to check out the last few hours. It looked like this one was more successful than the last one, but it still seemed like the group didn't work together as well as they could have. I think in-project communication was better this time (probably helped by the fact that it wasn't in a noisy bar), but it could have been better still.

In many ways, a six hour startup is like a microcosm of a real company with some of the same problems on a smaller scale. A whiteboard might work when you only have six hours and I know of at least one startup doing all of their project management using Post-It notes, but I keep seeing signs that I'm on the right track -- that there's a need for something better than a whiteboard but not as large or complicated as a typical project management or task tracking system and which is aimed at small business and other small groups. I'm also currently leaning toward calling the product itself "Groupthink Projects." That's not definite by any means and I'm interested in your thoughts.

And, on the project itself, right now, I'm still in the midst of a stage where I've written a lot and everything's broken. My plan is to emerge from that stage sometime tomorrow.

17 Days: On The Benefits Of Comments

For those who aren't software developers, I'll explain the the word code. In the early days of computing, programmers wrote short, cryptic programs that were unreadable by anybody who wasn't highly trained. In fact, even highly trained people had problems reading programs written by other people. This unreadability led to computer programs being code, as if it was "in a code" that required decryption in order to be read.

Flash forward many years and things have changed. We now write long, cryptic programs. But, we still refer to the lines of computer programs as code. Things have improved slightly through the addition of comments. While most computer code is either declarative (specifies something about the program) or procedural (actually does something), comments are notes placed in the code that are intended to be read by a human. They don't do anything -- except make the code clearer.

Like most programmers, I didn't always have good commenting habits. My first large program was 2,000 cards (yes, punch cards) of assembly language with nary a comment. These days, I comment everything -- even when I'm building a one-person startup -- and I don't just comment code. For example, I comment Illustrator and Photoshop files when I'm creating artwork where I might not remember what I did or why.

Not everybody thinks that comments are valuable. I've been told that I shouldn't write comments because it slows down development. The argument is that code should be readable without comments and that it's faster to rewrite it from scratch later if there are problems than to write comments in the first place. Unfortunately, all code -- including my own -- isn't nearly as readable as the authors would like to believe. Sure, good variable naming and other things can help, but they don't substitute for comments explaining what's going on or why the code is written like it is.

Recently, I had a great example of the value of comments. I broke something that had been working before. What happened? There was a slightly complex chunk of logic that seemed to be failing. Fortunately, I had commented the code, so I knew exactly what it was supposed to do without having to remember the details or figure it out from context. When I looked at the comment and the code, it was clear that they didn't agree -- I had inadvertently deleted something while making an unrelated change.

Yes, I could have used the debugger and figured it out, but such bugs of omission are hard to find -- after all, the code that isn't there just isn't there. My comments turned a potential crisis into a 1-minute fix. And, whether you're building a startup in 30 days or you're taking a more leisurely pace, that's a good thing.

Moral of the story: Comment your code, even if it's just for yourself.

18 Days: Closing In On Group

As I mentioned, there are two key parts of Groupthink - group and think. For the past few days, I've been working mostly on group and I wish I could say I was done with it, but I'm not. The good news (I hope) is that group is harder than think.

And what's group? Group is the support for sharing and collaboration that underlies the data. It's the infrastructure I need to support the actual data and user interface. I'm on my third implementation and I might tweak it a little more after a discussion with Mike Koss today. I think I'm on the right track now, but Mike asked some good, tough questions and I'm going to take some time and think about it a bit more and make sure I'm not missing the boat*.

Similarly, over the last two weeks, I've had a lot of really good discussions with outside advisors and gotten some great advice. Every time I have a meeting, I learn about more things that I don't know! Sometimes it's daunting, but I wouldn't have it any other way. As Jamie Riche explained at Wednesday's Seattle Tech Startups meeting, it's better to learn the things that you don't know. And it's why I try to listen as much as I can in these meetings (though I know I also spend a lot of time explaining).

To everyone who's been giving me advice, thanks again.

[* One thing that's a bit frustrating about Google App Engine is the inability to run reasonable performance tests on database operations. When I have multiple ways of doing something with big differences in schemas and/or queries, I'd like to be able to have a definitive way of telling which way is more performant, and, basically, I can't. So, figuring things like this out means thinking hard.]

19 Days: Lose the Landing Page

Last month, I started having UX Office Hours at StartPad. For four hours each month, I'm available for whoever walks in to get some free advice on the user experience of their product. It's UX, not UI, because we cover a lot more than just the interface --it's about improving how users experience the product.

Today, one of the people was Mark Puckett of KExplorer. It was immediately obvious that he had done a lot right. He'd built something useful and, unlike a lot of things I see, it was neither ugly nor cluttered. Well, not very cluttered. He started with a very simple question about a feature that he wanted to add and how should he do that. We expanded the question to how could the whole page be redesigned to not only make it work better but to make the feature fit in naturally. I think we came up with some good improvements and a good design.

After we finished with that, Mark offered to show me the home page. I was a bit surprised because I thought we had been looking at the home page. It turned out that the front page was a landing page -- an introduction to the site with a bunch of information on it. The information might even be useful information, but the fact that Mark skipped over it when showing me his site is an indication of the problem. The landing page is an obstacle. It's in the way from the portion of the site that is the most interesting and the most valuable. My vote: get rid of it. Take the content in that page that is useful and integrate it into the new home page -- the page that we'd spent most of the time discussing.

Groupthink has no landing page. When you go to Groupthink, you're ready to get started. After all, that's why you're there. There isn't a page extolling the benefits and a "click here to get started". You just get started, whether it's your first visit or your one hundredth. This doesn't mean the home page (or the first page a user sees) can't do some promotion -- frequently, you need to do this, and Groupthink's does, under certain conditions. But, if your home page is a "landing page," you'll have a lot of users land there and then go away. This isn't what you want.

Landing pages aren't always a bad idea, but I'm hard pressed to provide examples of where they're good. If you're even considering having a landing page, take a good hard look at whether it's the right thing for your site.

Update: Lose the Landing Page, Redux

20 Days: A Non Productive Day

Today I had three long meetings, several other distractions, plus I was one of the speakers at the Seattle Tech Startups meeting tonight. In between, I got a few hours of coding. In short, I did a lot, but it seemed like a totally non-productive day. Two observations:

1. There are lots of way to measure productivity. I learned things at all of my meetings. And, each one might pay off in the future. So, it wasn't a waste of time, though it didn't help with my current deadline.
   
   
2. I knew going in that this would happen. It's almost impossible to avoid non-productive days in any project. While you can't really schedule for such days (and I've certainly seen it tried), I think you need to take it in stride and move on -- and hope you don't have too many of them. Tomorrow, I'll be spending four hours in UX office hours at StartPad, so I'll just have to be super-productive the rest of the day.

At Seattle Tech Startups, I was one of the speakers on the subject of Public Speaking, but I learned cool things from both of the other speakers.

One of the things that Tom Music presented was the idea of "Speech Patterns" (like design patterns for public speaking) for planning a speech. I really liked the idea and will probably use it in the future -- I think it will work well with the way I plan speeches.

Jamie Riche of Ideal Communications described the Johari Window, a cognitive modeling tool that I had not heard of before, and discussed various aspects of giving and receiving feedback. Now I have an explanation for my desires to share and get feedback! I'm definitely going to have to read more about this.

21 Days: Fighting Office Apnea

As I've mentioned, I'm working at StartPad in Pioneer Square. It's a great co-working space that's also helping out the startup community in other ways, such as having monthly talks of interest to startups and monthly office hours, where you can show up and get help from an expert. I'm holding User Experience office hours this Thursday from 2-6 (stop by if you need some advice).

I'm in an office with three other people and today is the first day where all four of us are here at the same time. This means that the office apnea index is particularly high today. If you haven't heard the term Office Apnea before, it's because I just made it up. Apnea literally means "not breathing," but most people who have heard the word have heard of it because of sleep apnea, a condition where people stop breathing periodically while they sleep. Many people occasionally stop breathing briefly while they sleep, but people with sleep apnea stop breathing over and over again throughout the night.

In many offices, including today at StartPad, we all stop working over and over again throughout our workday. Just like sleep apnea can prevent someone from getting a good night's sleep, office apnea can prevent someone from getting a good day's work. Today, somebody mentioned something about the new Apple laptops. Somebody else asked for help debugging. Another person offered some development tips that they'd just learned. I'm as much a contributor as anybody else, so I'm not complaining about my office mates. And all the information is useful. Even without office mates, there are things like Twitter to interrupt you. Each of these interruptions can result in yet another moment of "what was I working on?"

Interruptions aren't the only problem. Many of us tend to work on multiple projects over a long period of time. We're constantly asking ourselves questions like "What should I be doing?" or "What's my top priority?"

Groupthink can't hope to get rid of those questions. But I am hoping it can help with the answers.


P.S. The vote was 4-0 in favor of JSON over XML, plus my own vote which was also for JSON.

22 Days: I Have A Lot To Do

I have a lot to do! Despite working a long day today, I have nothing to show for it. Well, sort of. Groupthink's UI relies extensively on AJAX, which basically means that JavaScript in the page talks to the server in the background. I have to get this stuff working first, but it's just not very exciting. I haven't yet decided if I'm using XML or JSON for getting data from the server (it's trivial to change from one to the other, just a change in a template). I'm leaning one way, but I'm interested in feedback from others.

I have a slightly modified XYZ statement, after some feedback:

Groupthink is an information manager for people working together that allows them to easily and efficiently organize their work.

I'm not completely in love with the term "information manager" because I think people may think PIM, but it's the best phrase I have so far. Again, feedback welcome.

And, on an unrelated note, one of the mantras for server security is "never trust the client." What this means is that, even with a smart client in the browser, any information that comes from the client is suspect -- it might be from somebody trying to deceive the server. Even a small, new service like Puzzazz isn't immune. I found out today that somebody was making up URLs on the server, trying to get it to reveal the solutions to puzzles they hadn't solved. Because of the way solutions are safeguarded, it didn't work, but, because it didn't occur to me that anyone would try it, they got a Server Error. It's now fixed and such invalid requests are simply ignored. Maybe they forgot to read the FAQ:

Can I cheat?

That's up to you. The only person whose fun you will be spoiling is your own. If you think you're cheating, then we recommend you don't.

23 Days: Not Entellium

I have an unusual relationship with the people who are advising me on Groupthink: I listen to them.

Right now, Groupthink is just me, so I don't have a formal board of directors or advisors. But, I'm fortunate to have a number of friends who are giving me advice. Some has been solicited and some has been volunteered. I'll take it all. Advice from two of them affected what I'm doing by nudging me from two different directions. Good thing too -- my original plan was way too ambitious. And, as I mentioned Friday, another advisor nudged me to disclose what I was working on, which resulted in me finishing up my competitive analysis, my XYZ statement, and my story. That was good too. It gives me clarity, even though, as Mike Koss pointed out, it's got a long way to go.

Contrast this with Entellium, where they were lying to their board of directors. Entellium is an extreme case, but I think similar things happen all the time. Over the years, I've advised a number of startups - some listened to my advice and some didn't (and notice I'm saying "listened" -- you can listen to advice without following it). And years ago, I saw a company consistently lie to their board. It wasn't fraud -- it was just not disclosing some details about some problems -- problems that they could have used help with. Instead, the problems got worse. The day the board found out, the president (a founder and the largest stockholder) got fired. If you're not listening to your advisors, why do you have them?

So, when I write on this blog that I'm interested in feedback, I really mean it. And I appreciate the advice.

24 Days: Beachware

One of the names I considered for this venture was Beachware. It's a phrase that I coined and have been using for years. Simply put, Beachware is software that enables you to be at the beach. Rather than sitting in your office or your home, using my software, you can be sitting at the beach sipping a Margarita (or maybe a Grape Nehi). Yesterday, I wrote:

Sometimes that work might be about fun, like planning a vacation. In that case, I want to make that planning easier so you can enjoy your vacation more.

But it seems like the goal of many web sites is to keep you using the site as long as possible, not to get you done with your task and moving on.

You don't have to go to the beach. But, if you're using my software, I want it to be because it's making you more efficient, not because you're frustrated with how long its taking to accomplish what you want. I hope you value my software more because you can use it less.

25 Days: What Am I Doing?

So what am I doing? A friend of mine chastised me earlier today for not yet revealing what I'm doing, as if I was deliberately trying to create suspense. Actually, I wasn't. The truth is that I wanted my first message of what I'm doing to be a strong one. You only get one chance to make a first impression and all that. So I wanted to get my XYZ statement and my story in place before revealing what I'm doing.

After feedback from this friend and others, I've changed my mind. I have a first draft of an XYZ statement and a story. Both can certainly be improved on, but there's no reason that I can't improve them over time. And I benefit now by getting feedback before its too late. If you think I'm making a mistake, big or small, there's no better time than the present to speak up. So, here goes.

Groupthink is a tool for individuals and people working together that allows them to easily and efficiently organize their work.

Groupthink revolves around two simple concepts:

Group:		Making collaboration for day-to-day organizational activities amazingly easy. Most people work with others, but organizational activities are spread through email, shared documents, and even sticky notes. There has to be a better way.
Think:		Provide an organizational structure for your information but otherwise get out of your way. We all lose productivity to our lack of organization. Even organized people lose productivity because of the time it takes them to get and stay organized. But it's not my goal to foist my organizational system on you. The most important thing in organizing your thoughts is just that -- your thoughts.

Here are some not yet frequently asked questions:

If Group is one of the key concepts, why does the XYZ statement include individuals?

When we work alone, we are usually wearing many hats. Here at Groupthink World Headquarters aka StartPad, I'm wearing every single hat. The sort of things that make it easy for groups to work together can also help me work with myself. Aside from that, even when we are working alone, we may be relying on other for some things. Groupthink facilitates that. Finally, for the tool to be a good collaboration tool, it must work for every user individually. Otherwise, it cannot succeed as a collaboration tool.

Why does the XYZ statement say work? What about non-work?

I define "work" pretty loosely. If it's something that you feel you need to organize, it's work of some sort. Sometimes that work might be about fun, like planning a vacation. In that case, I want to make that planning easier so you can enjoy your vacation more.

If you're building a web service, why doesn't anything above say that?

Yes, it's a web service, but that's just the way it happens to be built. It's not Groupthink's purpose in life. Also, there's a decent chance I'll add Google Gears support at some point.

What's the difference between an organizational structure and an organizational system?

There are lots of organizational systems out there which prescribe particular ways of organizing your life, your work, your tasks. There are lots of systems because different systems work for different people -- we all have different work styles. Groupthink is system-agnostic. I don't guarantee that I will support what is necessary for your particular system, but it's my goal not to force you to use any particular system. And I'm interested in your feedback if you don't think you can use Groupthink with your system.

How is Groupthink different from ____________?

When you look at all the to do lists, task lists, notetakers, outliners, spreadsheets, databases, project planners, personal information managers, calendars, intranets, wikis, and combinations of the above, there are a lot of products that might be considered competitors in one way or another. And let's not forget Notepad -- lots of people use plain text files for tasks lists.

I've looked at a lot of them already (I completed my competitive analysis today), but I haven't seen one that's doing exactly what I'm doing, in the way that I'm doing it. But, at this time, I'm not planning to do a side-by-side comparison with any of them. I've got too many other things to do.

26 Days: Towards a Schema

Spent most of today on two tasks:

• Competitive analysis
• Defining the schema

The competitive analysis isn't a lot of fun, but it's essential. Among other things, I need it to write my XYZ statement that explains what I'm doing. For those who haven't heard the term, an XYZ statement looks like this:

Groupthink is an X (what) for Y (who) that delivers Z (benefit).

If you're building a business, your XYZ statement is your 10-second elevator pitch. It should be short and to the point. Right now, my description of what I'm doing isn't short and it's not to the point. And my Z, the benefits to the Y, doesn't explain at all how what I'm building is different from the competition. I need to understand them better in order to explain the benefits and differences succinctly. The XYZ statement is about the limit of what I can do on the business side.

To me, the schema is more fun. Fortunately, my schema is not all that complicated, but it's important to get it right because it can be very hard to change later. Schema problems that seem small can multiple over time, by affecting other architectural decisions. A flaw can ripple into your entire project, and it's even worse if you expose your schema (see this post). I know of one project where a simple schema flaw, made years earlier, turned a one-day change into a month-long project because a wall had been reached -- there was no way to move forward without fixing the schema, which also had to be done without disrupting the service.

Case in point: I just launched a web site with memberships and relationships between memberships, but they're different. On most social networking sites, including Puzzazz, relationships between members are reciprocal -- if you are my friend, then I am your friend (Twitter is a notable exception to this). But, on Groupthink, relationships are more complicated and, at the core, they are not reciprocal. Since relationships are an important component of Groupthink, had I designed the schema incorrectly, I would be regretting this for a long time.

27 Days: Beginnings of a Site

I had three objectives for today:

• Get the barebones of a site running
• Start on my competitive analysis
• Start on my jQuery investigation

Well, I got the first one done. The site opens in the browser. There's no content, no data, no anything. But you can sign up and set your preferences. That's something.

The competitive analysis has to be done and I really should do it sooner rather than later, but it's not my strong suit, so it's easy to procrastinate. But, I do now have a list of potential competitors I want to look at.

And the jQuery investigation -- I guess I'll start that tomorrow.

28 Days: The Name

I have a name for what I'm working on. It's Groupthink.

To some of you, that might be a surprise. You see, I've been using groupthink.com for more than ten years as my personal domain. Originally, I acquired it for some software that I've wanted to build for a long time. I even built prototypes, first on the Macintosh and later on Windows. But, I ended up at Microsoft and the plans stayed on the drawing board.

When I left Microsoft in 2003, I revisited the idea and ended up heading in a different direction -- I tried, unsuccessfully, to start a search technology company (Krypton Technology). Although I had some pretty great ideas and got great responses to my prototype, I couldn't find people interested in funding a project that would end up competing with Google, Microsoft, Yahoo!, etc. So, I filed for a patent and moved on.

Now it's 2008 and I find that I'm revisiting the idea yet again. I didn't plan it this way. I actually started somewhere very different, but, as the concept evolved, I found that a lot of my earlier ideas were resonating. I found myself asking questions that I had asked myself before.

This isn't to say that I'll be implementing a 15-year-old idea. Quite the contrary -- even though I've been asking myself the same questions, I'm coming up with very different answers. In the last 15 years, so much has changed and I have learned so much that the two projects are far more different than they are similar. But, at the core, they are both aimed at solving the same fundamental user needs. It's nice to know that I can meet those needs so much better today than I could have back then. And the name fits.

So, Groupthink it is.

29 Days: Technology Day

Top items on my agenda:

1. Flesh out the details of what I'm building
2. Figure out the technology I'm using

I actually have a pretty good idea of what I'm building since I've been thinking about these ideas for quite a while (more on that soon). So, that makes today Technology Day.

Server Side

I already made one big decision and that's to build on top of Google App Engine, which also means I'm using Django and Python. App Engine has a few limitations, including the lack of cron jobs and the inability to receive email, that I'm not happy with, but I can live without them right now. And, I think that Google will eventually lift these restrictions.

I did consider hosting this on my new ISP, DreamHost, where I have unlimited storage and unlimited bandwidth. But, alas, I don't get unlimited CPU. DreamHost is a great ISP, but they don't scale and I'd have to manage my own server installation. With App Engine, those issues become non-issues. When I weigh the advantages against the disadvantages, I think App Engine is a pretty good decision. And, if I really need it, I can write a small app at DreamHost to help me work around App Engine restrictions without causing scale problems.

Client Side

That leaves the client -- what do I run there? I briefly considered Flash and Silverlight. While they would certainly allow me to build a gorgeous client, they are heavy and would require me to create a separate implementation for mobile browsers that don't support them.

That means JavaScript and DHTML for all dynamic actions on the client. There are two issues here: the difficulty in getting everything right in every browser, with all the subtle differences, and debugging, which is a pain even with Firebug. Google Web Toolkit looked really promising. I spent a fair amount of time today reading documentation for it and came to the conclusion that it's pretty cool. It does a lot more than I need, but I'd get to use a real development environment and a real debugger. Unfortunately, the learning curve for using GWT is pretty steep. If I were doing a six-month or longer project, I'd seriously consider it.

There are a number of JavaScript frameworks worth considering. I've used Prototype and Script.aculo.us in the past (it's sort of the default for Ruby on Rails) and there were some things that I didn't care for. For one, they were written by different people and it shows. I've gotten the most recommendations for jQuery and Yahoo UI, so I took a serious look at both of them. Both are actually quite good with different strengths and weaknesses, but I liked the way jQuery was designed a bit better. So, jQuery it is.

Next steps: learn jQuery as I start building the server side of the service.

West Side

I almost forget agenda item 0 -- where am I working? I have a great home office and I work in it every day, but it's a home office. When I'm home, there are lots of distractions, ranging from the refrigerator to my kids after school. Even though I'll still work at home in the evenings and on weekends, I wanted to have a real office environment with minimal distractions. So, I decided to make a trek across the lake and work at StartPad in Seattle. StartPad is a co-working space for the Seattle startup community and it's where I'm now holding monthly UX office hours.

30 Days to Launch

I'm shipping a brand new consumer web service in 30 days. I better get started.

Flashback

A little over a month ago, I started building Puzzazz, a new puzzle site that I launched last Monday. For those who haven't been reading, I built it from start to finish, in my spare time, in less than a month -- using a language, a framework, and a platform that I'd never used before. It was fun and challenging. During my extra spare time, I started thinking about taking on a much bigger challenge, and I'm starting that challenge today, full time, with a plan to ship in 30 days.
 
Today, you can find "software as a service" -- applications supplied as services on the internet -- all over the place, from Google to Microsoft to thousands of small companies. But I'm not new to building consumer software as a service. I built my first consumer web service using AJAX in 1997, before most of the world had heard of software services and before the name AJAX was even coined. Sadly, that product was way before its time in many ways and the company didn't make it. One of the things I worked on at Microsoft was the bCentral Communications Center service. And, my last two companies, DreamBox Learning and Sampa, are also consumer web service companies, for educational software and family web sites, respectively.

Fast Forward

This time, I'm going to build a consumer web service that I've wanted to build for a long time. I'll be giving more details soon, but, for now, I'll just say that it's a new take on a simple idea. Like almost every other idea you can come up with, you could say it's been done before. But I have some new ideas. What I hope to do is combine the right set of features and usability so that I end up with, as Goldilocks would say, something that's just right.

30 days is either an eternity or no time at all, depending on how you look at it. I have enough time to build something that's pretty useful. And I have little enough time that I won't be able to throw in the kitchen sink.

Starting today, I'm going to try to blog about what's going on every day.

And Then What?

Well, I'll ship it. And I'll see what happens. I hope you find it useful.

After that, I'll be available for consulting gigs or maybe even the right "real job".