OverviewThis pages outlines the rationale for using RapidWeaver for digital portfolios or for switching to RapidWeaver from either Netscape Composer or Apple's iWeb software. This page has it roots in the Portfolio +4 project by Brubaker, Ault, Hofer, and Holloway (2006), who identified five main evaluative criteria for construction tools/methods for Ball State teacher education portfolios:
- Direct publishing within application
- Multimedia (graphics, videos) support and iLife integration
- File management
- Ease of use
- Site navigational structure and customization options
Pedagogical RationaleEasy, Early Success. It is important that the construction tool students use makes sense to them in relation to prior experience. However, direct instruction is still needed (regardless of the platform) to provide the foundation for continued exploration with support from peers and portfolio support staff and students. Apple's iWeb and RapidWeaver both do this very well.
Integrated Media. Today's students need a fluid means to bring in various kinds of media into their portfolio. The application needs to bridge the iLife media with their portfolio. Apple's iWeb and RapidWeaver both do this very well.
Durable, Yet Flexible, Organizational Structure. The portfolio needs reflect the student's own sense of style and structure but with a navigational framework that is consistently executed on every page. RapidWeaver supports an easy method for achieving this with options to change the structure over time, for the whole site or per page.
Multiply-Related Artifacts. This is probably a problem that is under-recognized. Almost all artifacts in almost all portfolios are "associated", "related", or "linked" to one and only one INTASC standard (but most artifacts relate to multiple principles in INTASC and content area standards).
Ongoing, Autonomous Production. Web construction and publishing needs to be frequent and contextual. By the end of their freshman year, teacher education majors need to master at least one web construction tool so that they can continue working on their portfolios and making connections regardless of their academic programs.
Technical Rationale for RapidWeaverBelow are a few key advantages of RapidWeaver, some of which are further addressed in the Portfolio +4 site.
Uploading just changes. To promote frequent, ongoing work on the portfolio, students need a tool that can permit uploading of quick changes to their sites. RapidWeaver supports this with one click.
Portability of Site and Sites. Students can create multiple web sites that can be easily exchanged with each other (as a file on a flash drive or in iLocker) and published to Ball State or other web servers using FTP, WebDAV, and dot Mac technologies. It also allows students to work on multiple computers, anywhere there is a Mac. Note, the HTML code RapidWeaver produces is Internet standard and platform independent.
Nested Menuing. This permits students to easily define the navigational structure of their sites. In RapidWeaver, the navigation menu is created by dragging pages within each other to determine how they are nested. Updates are automatic and students can focus more on writing and content production.
Relational artifact structure. This sounds more complex than it is. It is really an easier way to develop rationale statements linked to artifacts and to INTASC principles and other standards. See the RapidWeaver Models page for information about a blog-based portfolio.
iWeb Strength (for the Ball State context and compared to RapidWeaver)Free-form page design. iWeb does a great job with individual page layout. However, with the Blocks plugin, RapidWeaver has the same free-form page design as iWeb.
iWeb Limitations (for the Ball State context and compared to RapidWeaver)Limited Navigation Options. iWeb can not do nested menus and cannot treat areas of the page equally across all pages of a site (such as common sidebar, header, and footer areas).
One site only. iWeb places all content into one hierarchy. While students can create multiple sub "sites", they are exported hierarchically within one parent site (called "Home"). This prohibits students from creating distinct project sites that they may want to share with others and for which they do not want interlink with their portfolio.
Domain file. iWeb is inextricably tied to the machine one is using. With only one file (called the domain file), students can not work on any other machine but their own. It is possible, but awkward, to move the domain file to other computers.
No direct uploading. iWeb was designed to directly publish only to Apple's "dot Mac" servers. Ball State students have to use Fetch to upload their iWeb content AFTER they have exported their iWeb content in a multi-step "Export + Upload" process.
No ability to upload just changes. With this multi-step "Export + Upload" process, the student can not easily upload just the changes to his or her site: The student has to upload the ENTIRE site every time. As the sites grows with more digital media like movies (something that is advocated), the upload time gets significantly longer.
For more information, visit www.bsu.edu/istudio/rapidweaver/
Acknowledgments. This page was written with feedback and input from the Portfolio +4 students (Andrew Brubaker, Joe Ault, Brooks Holloway, and Adam Hofer) and the students in the iStudio (Julie Biddle, Wei Ma, Diane Glosson, Ryan Johnson, and Liz Green).