We're off to the races with Prototype 2, and the masters students have made a strong showing. I will post links to their sites as they make them available in the next day.
All students should post their reviews using the tags: GroupName groupproject prototype2 review, where GroupName is the name of the group and the rest are as usual.
By Iteration 3, I want all groups to have their mash-ups working equally well on IE and Firefox. I want all DOM issues cleaned up. That little bit of work will make the code base much easier to work with.
Here are my remarks from the presentations:
EducationChuser: This group has made great progress in its user interface since Iteration 1. They now have directions for how to use the site. One great new feature is the ability to add user reviews of universities. One area where I would counsel this group to exercise caution is in the features they add. I'm not sure the CNN feed on the site adds more than marginal value. They're thinking about adding events near the university which might be better (but they should not underestimate the challenge of EVDB). They're also thinking about allowing university administrators to add information. Very interesting.
Eventmaps: This group has an amazingly simple interface that probably requires no instructions, but they've made good progress exploiting the difficult EVDB interface. I particularly like their calendar date interface. They've added an ability to input into EVDB via the site and want to migrate this to keeping the user at their site inputting events using the API. Sounds tough but good. One issue this group had was with their presentation. They were trying to demo a feature, but it did not show up in any of the events they had. A good approach here would be to take a screenshot of it working and use that to illustrate what you've done as a stand-in for when the demo breaks. Not quite as good as a working demo, but it shows where you've tried to go.
Webfinancial has made tremendous progress with XBRL. Ryan (who should blog more) has done the back end work. Essentially, he broke down the rather complex XBRL data format into simple XML datagrams that the rest of his group can use to update the web page. Tony and Tanika did a nice job with a new summary display of the data they are pulling. Vershon (who also needs to blog more) should also start using elements of this data stream by the next iteration. This group has done a tremendous job sorting out their data stream so that they can get something useful out of it. They should focus their future efforts on making sure all that that work is effectively displayed by the front end.
Kayakers wins "the most progress" since the last iteration award. Lori and company got rid of the cross domain security issues they were facing by using a php pass through proxy to route all xmlhttprequest object requests through their own server. Lori also made effective use of the venkman debugger to get rid of numerous other issues in their code. The application has sped up rather dramatically and looks nice. The group was discussing dramatically updating their html for more aesthetic appeal. Other groups may also feel this urge. Let me advise that all think twice before doing this. Recall that our DOM updating methods depend on the DOM being well-formed. The more complex your html, the more likely you are to make a mistake and not have a well-formed DOM. I like the group's idea of using more data elements from the kayak api.
Concerquest continued the trend in IS449 of sowing some back-end oats to get better performance. Essentially, the MapQuest API only lets plots 10 points at once. However, the events service they are using, EVDB, may provide many events. Jason (who needs to blog more) developed a mechanism for looping through a set of returned events in groups of 10. Todd (who blogs almost enough) focused on converting the returned events into a tabular format. I like the group's ideas about inputting data into he EVDB database (Joe's future contribution). My sense is that they might be better off limiting the energy they put into parsing the text values of the returned EVDB elements. Also, their results within a 100 mile radius include Texas. The simple fix here is to just not give the 100 mile distance.