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.

Here are the projects:

• EducationChuser (courtesy of Raji who also provides slides)
• EventMaps (courtesy of Usha who also provides slides)
• update: Concerquest (courtesty of Todd who needs to provide slides)
  
• update: Webfinancial only works with Firefox (courtesy of Tony who provides slides)
• update: Kayakers requires Internet Explorer and you must change a security setting (courtesy of Lori who provides slides)

I will add more as they come up.  These first two are both excellent examples and impressive.

update: Concerquest uses the mapquest api, an interesting departure from the google api.  In general though, they are using popular and relatively well understood APIs.  As a result, it's easier to show spiffy results fast.  The group is, however, having to figure out some limitations in the mapquest api.  I look forward to them figuring out how to get data into the evdb service using their interface.

The challenge for webfinancial is dealing with a unique, complicated, and not so well documented XML format.  They are also having to make use of a pass-through proxy to facilitate their reliance on xmlhttprequest, so this group has had a fair amount of backend work to do.  I like this group's innovation and pluck.  They've managed to cut through the forest of something completely new and get some results.

Kayakers learned the meaning of the motto "Data is the new Intel inside" early on in their project.  They did a great job of getting kayak's unfriendly api to work.  The api requires three handshakes in order to deliver data, sometimes causing a noticeable delay.  Eventually kayakers could probably benefit from a pass through proxy implementation.  I thought they did a good initial job of figuring out the kayak API.

Educationchuser also faced the "Data is the new Intel inside" issue.  They had to construct their own data format for colleges in a four state area.  They are currently developing a database that will hold user contributed reviews of these colleges.  That's neat because the data will be unique to them.  The group's progress on the first iteration is notable because they spent a lot of time trying to get a seemingly hopeless web applcation framework, dotnetnuke, to work.  I would like for testers to pound on their iteration one interface to give them good feedback.

Eventmaps had the best model of their target audience of any of the groups (grad or undergrad).  That really helped them refine their feature set and vision.  They also had good project management.  Prototype 1 was good.  I'm looking forward to seeing them insert data into the evdb database.

In summary, the major goal of Iteration 1 was to get something up and running that showed your project idea.  We also wanted to establish a concept of what the end result would be.  All groups succeeded in this objective, and I am proud of the progress both classes made.

An observation I would make across the board is that all groups need to get contributions from all of their members.  I don't expect members to contribute in the same way, but all members need to contribute their share of effort.  I will be speaking to groups on specific points where I see this to be an issue.