Times and Timezones can be a pain as well. I was definitely happy that I ran across a method of automatically converting dates to the proper timezone with Javascript. Ecmanaut has several interesting articles on dates, times, and usability, the relevant one being on timezone best practices.

One of the commenters pointed out a post at RedHanded on something called PerfectTime. The article pointed to a more elegant version by Mike West, which was great except for it’s use of an invalid attribute, which he addressed by using the <abbr> tag.

These are very clever ways of getting localized time without a lot of back-end infrastructure and coding, which I like. I’m not sure if this will be the most appropriate way to handle things in Events, which could have dozens upon dozens of times, so we’ll have to keep an eye on performance, but I really like these as good starting points.

The only other issue I’d be concerned with would be browsers with improperly set times/timezones… I have no idea how prevalent that is.

Today I isolated a particularly frustrating bug. During the event creation process, clicking on any form field was producing an “uncaught exception” in FireFox.

uncaught exception: Permission denied to get property HTMLDivElement.parentNode

I finally isolated the problem to be coming from Matt Kruse’s Calendar Popup but could not, for the life of me, figure out what was causing it or how to get rid of it. Luckily, I remembered that I had seen the same calendar on MyPunchbowl, so I ran over there and grabbed their copy of the javascript file. I’m not sure what they did to it, but it’s no longer throwing errors. Thanks, MyPunchbowl!

Between the Peekaboo Bug and some issues with prototype, we were having some fairly annoying issues with IE6. A few hours of tearing my hair out this afternoon seems to have produced a solution. For now.

Thanks to PositionEverything.net and Prototype’s latest stable release, things seem to be fine.

The only problem now is that some of the effects cause a “Stack Overflow Error at line 0″ in IE6. I think this is more a function of my “standalone” version of IE6, but I’ll check on some older computers at the office next week to be sure.

Fresh back from Baltimore for a close friend’s wedding, and ready to get back at this whole development thing. The most pressing issue right now is that the new design (for a reason I have yet to diagnose) looks horrible in IE6, and many of the effects simply do not work. This is a bit of a set-back, but hopefully it won’t be too bad to fix.

When you’re just throwing a site together, or when you anticipate a small (or highly technical) audience, some of “supporting characters” on the site might not need to have the same level of investment as the the main features. Take user registration, for instance. A few fields tossed on a barebones form, a submit button, and some slightly less than cryptic error messages might suffice in some cases. In this case, though, we felt it was important to make every step of the process as usable and user-friendly as possible. That’s why I spent more time designing, tweaking, and coding the PostFresh registration screen than I have any other I’ve worked on. I’m pretty happy with the result.

The main feature of the registration screen is preliminary validation of all of the required form elements. We use AJAX to check the availability of the username, your email and password are evaluated in the browser, and you even get on-screen confirmation that your passwords match. In addition, each field has specific instructions as to what is required.

Over the coming week I’m hoping to get the rest of the user management features finished up, including integration of the TypeKey and OpenID systems into the login and event handling. After that we move on to event management. Hard to say how far out we are right now. I’m guessing sometime in the second half of June we should be ready for initial beta release. The plan is still for that to be a relatively limited release. More to come on that this week.

We’ve been around enough to know that the way a site handles your data says a lot about them. Gmail does a decent job of keeping spam out, but I don’t like the idea that some site I signed up for is going to turn around and sell me out to make a quick buck. At the same time, it’s important that the privacy policy isn’t so strict that growth (by ethical means) is hindered. That said, we put a draft of the privacy policy together today, and I hope that it gives enough protection to everyone involved. If not, that’s what drafts are for… feel free to leave a comment or send an email if something seems off to you.

Although it seemed as though we had dropped off the face of the earth, we’re back and the new design is live. We’ve got a little bit more development before we’re ready to open registrations again or do any more demos, but this is a step in the right direction.

School and work came between us and our pet project for a few months, but we’re back on the horse.

Anyway… go check it out. Your comments are welcome.

In the next week or two things will start back up again in a major way. In the mean time, have a look at a screen shot of the design that we’re working on implementing:

We’re pretty happy with it.

Lots of work going on behind the scenes, but not much to speak of. The site design is coming together and we’re putting the finishing touches on the business plan. New features are still coming slowly, although we’re going to be pausing that soon when we start to deploy the sexy new design.

One thing worth mentioning, though, is that my problems with opera and Script.aculo.us/Prototype have been cleared up thanks to a commenter who suggested that I download the version of prototype that was being used on the Script.aculo.us site. That cleared the problems right up. Hopefully the forthcoming release of prototype doesn’t contain these same bugs.

After the public demo, which went smashingly well (big thanks to Orson from EDSBS for joining us), our plan was to move forward into something of a Beta phase. No major bugs were uncovered during the demo, so that plan will continue apace.

More specifically, development will continue with the actual event application, but there’s lots of administrative things that need to be developed now, too. The final design should be agreed upon this week, and then it needs to be implemented. There are a few more features we want to get worked in (including Pagination for those long events, and Remote Blog Integration, which I’ve talked about before) and we’ll also be putting together a short video showcasing the features.

From this point things could happen quickly, or they might take a few weeks. Time will tell.