Slashdot Mirror
Suggested Curriculum for 'Complex Websites' Class?
StudMuffin asks: "I teach graduate computer science courses at a Big 10 university to grad students, who have never programmed before and are studying Human-Computer Interaction or other Information Science specialties. These courses are usually their first dip into the programming pool, so we have tons to cover in three months. This fall, I have been asked to take over and redesign our 'Complex Website' course, which is getting a bit long in the tooth. This course has traditionally been about database backed websites with server-side scripting. My only requirements are that there be coverage of PHP and that we have basic instruction about persistence using a database (which must be MySQL). However, I believe that the nature of 'complex' websites has changed, with XHTML, CSS, Javascript, web services, and so on. Sites like Google Maps make the browser feel like a fat client and are making the web browser a true window onto enormous data sets, and take into consideration the MoRAS of small views on large worlds. What do Slashdot readers consider a reasonable curriculum would be for a redesigned course like this?"
I'm a somehwat experienced developer specializing mostly in web related things. In the past year, I took two classes at Ohio State that are related to what you describe. One was a design class (think print design) using the web as the medium. The other was a usability class geared towards engineers (Industrial, Cognitive) which revolved largely around a data driven web project. The engineers all had taken some kind of freshman class where they wrote "hello world" in C.
My first bit of advice is that first time programmers/web site creators invariably tend to get mired in the technical details of implementing things. It becomes very hard to see the forest for the trees.
In the design class, students spent the majority of their time struggling with Dreamweaver/HTML/CSS. In the Usability course, they spent most of their time struggling with FrontPage/ASP/Access/HTML. If the focus of your course is HCI, it may be a mistake to be teaching web coding skills because this will detract from the true focus of the course. If the focus of your class is to give them web development skills, then you still may be better off looking at the big picture instead of getting mired in web implementation. If you are trying to give them web implementation skills, it may be better to give them structured fill-in-the-blanks homework assignments instead of an open ended project.
So moving on, if you're going to teach the programming skills, you want to make everything as simple as possible.
First off, consider not using MySQL. Instead, consider using MSDE and Access Data Projects (adp). MSDE is a free version of MS SQL server. The one big difference is that MSDE has a governor that prevents it from hosting high traffic databases. Access Data Projects (adp files) let you connect to an MSDE/MSSQL database using access as a front end. This is similar in principle to linked tables in access but it is much better. You can create msde tables and views in access while you can't do that with linked tables.
Using MSDE/ADP will make things much harder on you for setup, but much easier on the newbies. Here is the basic reasoning. People know access or if not they can figure it out via the stumble method. You can make and store somewhat complex queries as views without knowing SQL. An interface like phpmyadmin or even the new mysql query browser or the buggy admin interface is frightening in comparison.
For database access, don't teach them sql, mysql_connect style functions, or pear::Db. Instead, teach them DB_DataObject. DB_DataObject is the standard pear data access layer generator library based off of Pear:DB. You point it at a database (pretty much any kind) and it generates an extendable class for every table and view. All classes inherit the base object's methods like insert, update, and delete. It has a fairly simple yet modestly powerful search/query interface.
Why use DB_DataObject? It is much simpler than peardb/mysql_conect alternatives. You don't need to mess with connection strings. When combined with the capability to make views, you probably don't need to mess with any sql at all except in a few rare circumstances. The interface is consistent and it introduces them to valuable notions of a data access layer, object orient programming, the benefit of community libraries, etc.
Incidentally, there's some other libraries that plug DB_DataObject into HTML_QuickForms so that may have perks.
That brings up another point. Don't teach them anything involving html forms. Instead teach them HTML_QuickForms (another pear library). Again, the advantage here is that html_quickforms are waaaaay easier to understand and work with effectively than are plain html forms... especially when it comes to input validation. Of course, they are not very easy to format without using the Smarty template renderer and that opens a whole other can of worms (but you might want to teach templates anyway).
Anyways, I've just got done teaching a