The design of this site reflects more an on-going experiment than an attempt to produce a polished document. I use the site to communicate, but also to try out new tools and standards, and to extend the development of the Inquiry Page, iLabs 2, and iLabs 3. In this spirit, please see Sami Serola's Collaborative Authoring Tools (CATs) project. The subsequent secitons provide details on the current design. I welcome your comments and suggestions.

I created the backbone structure for the site in XHTML 1.1 (Extensible HyperText Markup Language). Nearly all of the pages use server side includes (SSI), meaning that (usually small) files containing content for display are inserted at run time. This facilitates updating since the same content, such as my postal address, may be needed in several locations on the site. The use of SSI's is the explanation for the .shtml extension on many of the files.

Where possible the design conforms to the World Wide Web Consortium (W3C) standards for to improve accessibility, interoperability, and evolvability. I generally avoid the use of frames, animations, and other (sometimes useful) devices, which creates problems for some web browsers or low-bandwidth cases. I do use Cascading Style Sheets (CSS) to facilitate site-wide changes in formatting, such as changing the width of the side menu, font styles and size, colors, and other appearance features. See my main style sheet.

The site uses a mix of tools (aka bricks). It is a personal information site, but is also evolving into a Community, Content, and Collaboration Management System (C3MS), using the terminology first proposed by Daniel Schneider's group at TECFA (see http://tecfa.unige.ch/proj/seed/catalog/docs/edmedia2002.pdf, 2002; http://tecfa.unige.ch/proj/seed/catalog/papers.html). The advantage of a C3MS bricks design is that it is possible to integrate various tools into a more comprehensive system. One current disadvantage is that it is difficult to maintain a consistent appearance across pages.

For example, over time, much of the content I created initially here has been moved to the Inquiry Page and I included a search command for my Inquiry Units in the sidebar. I also use version 2 iLabs bricks for content such as lists of resources and a web log. I use version 3 iLabs bricks for other functions, such as a forum and document center. The reasons for this mix of Inquiry Page, version 2, and version 3 iLabs bricks are mostly convenience. In some cases it is not easy to migrate content easily across the systems, or different systems offer unique functions. Although I make extensive use of these C3MS support systems, I chose not to use the default home page display, because I wanted to have more control over the design and to mix bricks from each of these, as well as other systems. Thus, the iLabs default "home page" simply redirects to my home page.

The use of the iLabs has an additional benefit beyond the individual bricks. Although I do not use the default home page per se, it still exists, is indexed, and when made "public," can be located using the browsers and search tools within the iLabs spaces. Thus, users can find the site within the context of other iLabs.

The site also contains a personal information manager, hidden from the ordinary user. That portion includes a to-do list, a travel/presentations list, a research notebook, a document center, and other tools/bricks.

For course syllabi, I create two iLabs, one for the public version of the syllabus and one as a workspace for students. The former contains the rationale, readings, and assignments, while the latter contains a Bulletin Board and Document Center for student work. In the public iLabs, I use the List Tool to create different parts of the syllabus, such as the dates and orientation for each class and the specifics about the assignments (see an example at http://ilabs.inquiry.uiuc.edu/ilab/pragmatic/).

Within each class session, I use Inquiry Units for the major content. There are several advantages to this approach:

• information specific to a course offering, such as the dates and place of the class is separated from the substantive content, such as readings and activities. This facilitates updating and re-use of materials;
• the Inquiry Units can be used as is, edited directly, or customized as needed using the spin-off feature;
• customization can also be done via meta-information in the syllabus entry;
• students can spin-off Inquiry Units directly from the syllabus for assignments or projects;
• multiple Inquiry Units can be included for a given class session, thus allowing different grain sizes for activities.

I considered using iframes (ilayers) for the inquiry units in the syllabus, but there are the familiar problem with frames, that the address bar shows the last object loaded, not the syllabus url. Also, some browsers don't display the frames properly.

I use a Creative Commons license specifying how users may distribute and use the content (by attribution and share-alike).

There are several different versions of essentially the same idea, that technologies are frozen processes. Marx had his version as does Dewey via Hickman. Here are some postulates around the idea:

• We think of technologies as tools to solve problems, but problem-solving also creates technologies (regardless of whether the solution is a new term, an artifact, a process, a machine, etc.)
• Technologies are thus constructions, and re-constructions through use (e.g., Ron Eglash on "appropriating technologies")
• We deem a trace of problem-solving to be a technology when we envision future needs to address similar problems, e.g., workshop activities become an agenda, then a model, then tangible materials (web site, poster, handouts), then online technology. Thus technology-ness (ugh!) is a relative property expressing our assessment of a process's fixity and its reusability in future contexts.
• A device, e.g., a PC, isn't a particular technology until it comes into use, in which case, it can realize any of an indefinite set of possibilities. In that sense, the user is not the recipient of the developer's work, but the ultimate creator of the technology--if I use my PC as a doorstop, I've constructed a kind of doorstop technology.
• The cycle of problem-solving to technology to next problem-solving to next technology, etc. means that at any given point one can view a technology as a description of the process of past problem-solving or a means for future problem-solving. This is reminiscent of Dewey's reflex arc paper, in which he shows the arbitrariness of stimulus v response (that each "response" can be seen as a "stimulus" for future action.)
• Artifacts thus manifest the problem-solving activities that gave rise to them (cf. Madeline Akrich on the thickness of the metal in a car body), while simultaneously providing the structure for future activity (as Lev Vygotsky shows).
• This view counters both a naive constructivism that views all activity as fluid and agentive, as well as a naive determinism.
• There are important implications for design, development, distribution, use, and evaluation.

I edit the files using BBEdit 8 and use Interarchy 7.3 file transfer software to synchronize files between my Mac OS desktop and the web page server. You can see other tools and credits at Site tools.