I was thinking just embedding a Google calendar...

Quote:Original post by Gaiiden
I was thinking just embedding a Google calendar...

Same here.

I do like the sound of being able to filter the content to certain topics, which I'm not sure is so easily supported using an embedded Google calendar. How much control is offered over the display and content?

Does a Google Calendar potentially allow all our users/partners/customers to add items to the calendar, in some cases only after we've approved the item data? If so, ok, I'm down with that. Oh, yeah, and it'd have to let them add and edit only their own items without requiring Google accounts...?

right right. I can also see how it would be easier to integrate the event calendar into user's accounts and everything if it was built into the system itself. Perhaps a better way of putting it would be I was thinking of leveraging Google. I dunno if they have any kind of API in place for extending their calendar but it would be nice to be able to have all that functionality in a popular web-based calendar that can be shared outside the site

In regard to topical organization, code.google.com notes, "Your client application can use the Google Calendar Data API to create new events, edit or delete existing events, and query for events that match particular criteria." (Emphasis mine). I don't know if it would be possible to sort the events in a way that seemed consistent with the rest of the site, but it's definitely worth looking into.

Yeah, if the API allows it then Google Calendar is a great possibility. And since it's software it can bend to your will. If anything, we can use a calendar component and hook into the data that Google's API provides.

I've become a big opponent of custom/roll-your-own solutions when trying to create a product (i.e. you're not doing it as a learning experience). My dislike for custom software has grown out of my experiences in witnessing the failures of custom software and the successes of high reuse. GDNet's software, for instance, is an admitted failure because the custom nature of the design and code didn't allow us to quickly adapt to change. I'm concerned about V5 as well because it's headed down a similar track in its development (long development time, focus on "custom" site needs - debatable, etc.).

Even if a piece of software doesn't do 100% of the things you need, people seem to forget that it's software and it's possible to work around the limitations of what you're using.

If I were to start GDNet again, this site would be driven by one of the CMS's out there that drive most other major media and community sites as the framework, then I'd use custom components and other features I wanted that the CMS didn't provide and integrate them into the CMS. With this approach a prototype could be had within 2 months. Of course, in 1999 there was no such thing as a CMS, so we sort of built our own, but in today's world not limiting the amount of custom code for a community/media site like GameDev.net can be detrimental long-term.

Anyway, off the soapbox. I've brought up these things before to blind eyes and deaf ears.

I think the calendar layout is fine. It looks like a calendar!

Quote:Original post by Khawk
I've become a big opponent of custom/roll-your-own solutions when trying to create a product (i.e. you're not doing it as a learning experience). My dislike for custom software has grown out of my experiences in witnessing the failures of custom software and the successes of high reuse. GDNet's software, for instance, is an admitted failure because the custom nature of the design and code didn't allow us to quickly adapt to change. I'm concerned about V5 as well because it's headed down a similar track in its development (long development time, focus on "custom" site needs - debatable, etc.).

Even if a piece of software doesn't do 100% of the things you need, people seem to forget that it's software and it's possible to work around the limitations of what you're using.

If I were to start GDNet again, this site would be driven by one of the CMS's out there that drive most other major media and community sites as the framework, then I'd use custom components and other features I wanted that the CMS didn't provide and integrate them into the CMS. With this approach a prototype could be had within 2 months. Of course, in 1999 there was no such thing as a CMS, so we sort of built our own, but in today's world not limiting the amount of custom code for a community/media site like GameDev.net can be detrimental long-term.

Anyway, off the soapbox. I've brought up these things before to blind eyes and deaf ears.

Hey, you and I are in complete agreement. The value in GDNet is not the software. To be perfectly blunt, I have no objection to scrapping the custom work so far and focusing on customizing a CMS. And I can guarantee that with that approach we'll be able to deliver V5, completed, in time for the 10 Year Anniversary this July.

I'm outnumbered on this, so I gave up fighting it and focused on what I could do to help.

Quote:I think the calendar layout is fine. It looks like a calendar!

Cool. I'll look at the Google API and see if we can't just skin their component.

Quote:Original post by Oluseyi

Quote:Original post by Khawk
Anyway, off the soapbox. I've brought up these things before to blind eyes and deaf ears.

Hey, you and I are in complete agreement...

I know, I remember. I didn't necessarily mean to get on the rant in your blog. [smile]

Quote:Cool. I'll look at the Google API and see if we can't just skin their component.

One thing I thought of that might be nice is the support for different views of the calendar. I didn't really see that in the screenie you posted. I'm thinking of something like how Outlook has the day, week, month view. Of course, I wouldn't expect people to use GDNet as their primary calendar so my guess on good views for us would be month, quarter, year since they are more of the macro view.

Question regarding the redesign in general if I may:

From time to time I use my iPhone to browse GameDev. With all this dynamic and graphically fancy stuff, how accessible will the new version be for limited (but modern) devices like cell phones and portable consoles?

Quote:Original post by WanMaster
Question regarding the redesign in general if I may:

From time to time I use my iPhone to browse GameDev. With all this dynamic and graphically fancy stuff, how accessible will the new version be for limited (but modern) devices like cell phones and portable consoles?

The iPhone actually has a fully capable browser, so we don't need to make any special considerations for it. I browse Ars Technica on my iPod Touch, and even their new, AJAX-laden design renders and operates perfectly on it. The only problem would be if we used Flash or Silverlight anywhere.

As for other mobile devices with, shall we say, less capable browsers (*cough* Blackberry *cough*), there will be a mobile stylesheet that condenses core information and eliminates superfluous graphic flourishes. It is imperative, however, to lay out what that information will be. In other words, the mobile stylesheet will be designed after all information pages have been mocked up.

Good point, though. Thanks for bringing it up.

Quote:Original post by Khawk
One thing I thought of that might be nice is the support for different views of the calendar. I didn't really see that in the screenie you posted. I'm thinking of something like how Outlook has the day, week, month view. Of course, I wouldn't expect people to use GDNet as their primary calendar so my guess on good views for us would be month, quarter, year since they are more of the macro view.

Yeah, I had the same discussion with Richard yesterday. Our focus would be on the month, quarter and year, but if we find that Google Calendar has a robust API then we could figure out a way for registered/logged in Google users to import data from our calendar into theirs, right on our page. That way, they could then drill down to the day/hour view and append event information. For instance, if our calendar indicates GDC dates, they could then go in and block that out, then mark which sessions they'd like to attend at which hours using information from gdconf.com.

I'll definitely look into it.