Thursday, September 25, 2008

World War 4 Will be Fought by Bugs

Spend some time designing and developing and evolving software and it will feel like you’ve been through a war or two or three. There are never enough hours, never enough coders, and the design is always wrong. But, once you’ve fought through all those hurdles, you can proudly release your product. You can even release your product to the world if it is internet based.

And, that is when the fourth war starts. The bugs come crawling out of the woodwork, or in this case the software. Some of them are really little bugs that cause huge problems and some are really big bugs that cause little problems. Often, squashing one bug causes more, angrier bugs, to attack.

Bugs fighting WW4 on your turf are a big problem for a few reasons: 1) Your Beta users, most who don’t understand software or software development, will eventually grow weary of reporting bugs and may even stop using your product. This is obviously bad. 2) Your team of programmers (some people only have 1) will grow weary of hearing about the complaining Beta users as well as the bugs and might even be happy when the most vocal users stop using the system or reporting bugs. This is obviously worse. 3) While you are in the trenches fixing the bugs, that list of great new functionality that you had shelved until after the initial release is sitting collecting dust. This is really bad – especially if you happened to blog about all the really cool new features that users should be looking forward to using.

Our war is more of a conflict, actually. As it turns out – so far – the bugs we have found have been relatively minor and have been fixed quickly. Our problems exist more on the user interface front. It seems that when many first timers arrive at the web site they have a common question, “What do I do now?” So, as we’re fixing the bugs, we are also trying to make it more obvious as to what, exactly, we intend you to do. Then, you may do as you wish.

But, if you have the patience and want to test out some great new software and give us some feedback and help us squash some bugs and give us some usability tips, register, sign in, and tell us what you think

ETJ.

Wednesday, September 17, 2008

But, Why?

Well, we’ve done it. We have built some great software and, as you can see by the logo on the site, it is now available in a beta release. Granted, it needs a few enhancements from the User Interface and Usability perspectives (like it would be really good to be able to know how to get to the registration page from the login page and things like that) but overall, it works well.

Now, we find ourselves and our users asking the question… why? What does your software do? And the answer is that it does many many many things and it does them well and those things that it does are easily put to good work in a huge array of scenarios. It is the equivalent of being told that you can do anything you want to do. Unfortunately, when you are told that you can do anything you want to do, the result is that you often do nothing.

So, we are looking for our niche. That “thing” that we do. That purpose for our great software. When we find it, we will adapt our software to that particular niche. Then, with any luck, we’ll get some traction and a good user base and eventually reach far beyond our target niche.
During this exercise we are asking ourselves… what is it that people do? What is missing from the on-line experience in one particular niche? Is there something that people do not in New York City or on the West Coast that we should harness and make our niche? What do all those people in the middle of the USA do? Certainly they must be social, right?

As we continue our quest for a purpose, go ahead and sign up using the register page. Then, if you have any ideas for how you’d like to see this web service used, put it in the User Feedback crew. As your kindergarten teacher might have said, “There are no stupid questions and there are no bad ideas.” Of course, she was lying, but the converse is true, “There are good questions and great ideas!”

ETJ

Wednesday, September 10, 2008

New Releases, Bugs, and All That Running

PUBLIC CHALK Beta was finally released on September 6, 2008. Oddly enough this was also the wedding day of Matt and Sarah – our lead programmer and the woman who somehow tolerates John and me. Maybe she really does think that the functionality is cool after all.

We did release a bunch of really cool usability and behind the scenes features that you can check out the features in the new features blog.

As with any release, there are bugs. Some are very frustrating because they are things that we tested and fixed while in the development database that somehow managed to make it into the production database. Others are brand new “undocumented features” that we really don’t want but didn’t ever think of testing for. We have documented those and have them in the hopper to get fixed.

Here is a tip for anybody in the software industry… do not do a major release the day of your lead programmer’s wedding… especially if he is planning to go to Croatia for two weeks and be generally unreachable.

The good part about this release is that we have noted that despite the bugs that the software on the whole is generally good and useable even though it isn’t the prettiest user interface on the planet. We have also noted a bunch of things (not bugs) that will make the software even more usable and we will be implementing those in a future release.

For now, though, I think I’ll go for a nice long run. A 220 mile relay through New Hampshire actually in the Reach the Beach Relay. I’m leaving tomorrow and I’ll be back on Saturday night. This will leave John alone with his thoughts… unless a few of you want to join PUBLIC CHALK and talk to John in one of his crews.

ETJ

Tuesday, September 2, 2008

Open Privacy

Open Privacy is a relatively new concept that was ushered in with the Internet/Social Networking era. It is an oxymoron, albeit one that needs to be turned into a NOT oxymoron – whatever that is…

The problem starts when people, maybe even you, put personal information on-line that you’d like to share with other people who also happen to be on-line. You might, for example, want to tell your close friends that you won some money in Atlantic City gambling over the weekend. Okay, a far stretch, but it works for this example. The thing is that there is a fine line between Saturday night and Sunday morning and you really don’t want the pastor/rabbi/minister/etc… of your church/synagogue/mosque/temple/etc… to know that you are a gambler. And he/she just also happens to be part of the on-line community and would/could easily find out about your secret life in front of the slot machines and make an example out of you the next time they preach.

The social web sites at large seem to solve this problem by allowing users to block certain other users from seeing certain parts of their information. This seems to work rather well if the user is a “power user” and understands the nuances of the security scheme that is provided for their use. Of course, the security scheme can be as complex and confusing (and powerful) as possible if you are a “larger” social network presumably because enough people out there understand it (or just don’t use it) and can explain it to their friends (or spy on them) as appropriate.

The real problem comes in when you are a smaller start-up social network clamoring for users/members. On one hand you want to be as open (read social) as possible and on the other hand you still need to protect your user’s/member’s privacy all without confusing them. Start off too “open” and you lose a bunch of users/members who would rather be a bit more private and start off too “closed” and your social network looks boring and… no one wants to come to a boring party.

This is our current struggle at PUBLIC CHALK. Open enough to be interesting, closed enough to protect our members, and security simple enough that our members and users will understand and use it.

ETJ