Our web site team is attempting to keep our audiences' needs and perspectives at the forefront throughout our web site redesign process. It's not easy! We naturally think about the school in terms of our relationship to it, and we have the inside perspective. This often results in ideas for organizing the web experience that mirror too closely the organization's internal structure.

Although our audience list includes internal constituents, we must remember to pay special attention to the external ones. We started the process by building lists of audiences that we need to reach via the web site. Prospective and current families, students, alumni, and employees topped the list. Next, we used a protocol developed at OneNorthwest to identify the values and needs of this audience as well as what the school wants them to learn/do from their web site experience.

Next, we developed specific "user stories." We each made up two mythical users and described what they wanted from the site, how they used it, what else we wanted them to learn, and whether they had a successful experience. This exercise was terrific, as it harnessed the creativity of all of the members of our group (techies and non-techies alike) to come up with possible perspectives on using the web site that we had not previously recorded.

Staying focused on audience was pretty easy until we actually got specific with content. Two weeks ago, we started to translate our audience work into actual web site information architecture. How should we organize the content and services on the site to meet the audience needs we identified? Our work immediately returned to a more traditional form, as we started pumping out content outlines that mirrored our organizational structure or replicated existing aspects of the site.

Do you design web sites? How do you retain your focus on the target audiences when you begin to organize content and design user interactions?

tags: webdesign

Panelists

Jeff Huggin, Snoqualmie District: Dreamweaver, ASP, Access, IIS

Mike Stewart, Mt. Angel School District: Win 2k3, Dreamweaver

Austin James, Redmond District (OR): hosted solution (SchoolWires)

Jeff Dobbs, Beaverton: wrote a custom content management system (Oracle)

Mike Finstrom, Highline District (WA): custom CMS the supports Dreamweaver and Contribute

How did you go about determining what systems you would use?

Found experienced developer at the ESD.

Developed culture of people who embraced content management system. Now looking at Sharepoint for next iteration. Allows for both novice and advanced users.

Mandate from superintendent that every teacher would have a web page, and look and feel would be consistent. Moved to a hosted solution. Teachers focus on posting content rather than what color it would be. Hosted solution was equal in cost to licenses for Frontpage.

Ease of use a huge barrier to buy-in: from Frontpage to MS Word to emailing items to tech department. Currently a voluntary system who send content to tech director via email.

Cost considerations, Puget Sound ESD developers built different modules for administrative functions.

How many staff members in your department are dedicated to web?

Communications person is the key, tech staff devote small fractions to site. ESD helps with back-end tweaks.

One small fraction.

Office staff already typing this content for newsletters. Just have to copy and paste into web interface. Does switching and routing for district, does not devote much time to web site. Does CSS, HTML, graphic development (1-2 days per month).

Web content staff member. Who owns the web site? IT department or others? Distribute stake in the web site. They are going to have to enforce policy, IT trains and supports.

3 of 5 district communications staff devoted to web site. Each district has a web manager. HR posts jobs, contract changes. One SQL developer. Goal of 1000 contributors. Moodle didn't extend. Randy Orwin has hacked it to extent.

How many teachers are maintaining sites?

Web-publishing through FirstClass -- a lot of teachers were initially turned off by it. A number of teachers have gone out on their own. Working with ESDs to facilitate blogs, wikis, and web pages. Union prevents requiring teachers to create web pages. Receives blog requests daily. Biggest issue is support. Planning to use Drupal for teachers. (Beaverton)

Will have 100% by next year, per superintendent. Top goal is communication/contact information.

25% on teacher web sites daily. One teacher records lessons every day and posts them on web site.

Made it fun and easy, focused on content.

Biggest challenges

Support and training is very taxing on district resources. Space is a huge consideration, as all content teachers use now go into the database.

Training.

Administration wants more professional-looking web site with zero budget.

Other issues

Posting links to off-site content (okay with panelists)

Pictures of students online: centralized permissions to one form, to allow blanket ability to show many pictures on web site. Want to centralize permission for student academic work next.



tags: acpe08

Today, we discussed the potential for Drupal to serve as the back-end of a public-facing school web site. Only a few examples exist out there, yet Drupal continues to gain acceptance as an extremely capable system that is ready for prime-time. Twelve of us shared frustrations with commercial school web site companies who were difficult to work with or insufficiently responsive with new features. To my pleasure, I found that many of my colleagues at this meeting were thinking along the same lines. We know how to evaluate and adopt commercial software. How does one evaluate and adopt open-source software?

We have created a series of tests to determine the potential of Drupal to serve as the platform for the next version of Catlin Gabel's public-facing web site. Drupal continues to pass each one. This month, I had two successful meetings with Kitty, our web site content editor, and James, the creator of the current web site and thoughtful strategist on school web site design and implementation. I have found to my pleasure that this group working together is far wiser than I could ever be on my own. Now, we are working together to move this project forward.

We held two meetings in the last month to consider next steps for the public-facing web site and think about the strengths and weaknesses of Drupal to meet these needs. We need to move to a new web site platform in order to meet demand for features such as electronic newsletters and podcasts and to better manage the burgeoning volume of content that we would like to display on the site. The Drupal founders, from the early on, appear to have understood the exponentially increasing nature of information. All content units (nodes) are functionally equivalent, flowing through the site like water as the site administrator sets up guides to expose them in particular ways. You classify -- not compartmentalize -- content, which enables people to find items much more easily.

I am also trying out a conceptual model to seek buy-in from critical stakeholders for this project. One may summarize the model as follows.

Tinker: Over the past year, I have built five CMS sites for different purposes, giving me a taste of content management platforms and eventually Drupal in particular. 1 | 2 | 3 | 4 | 5

Research: I have gone looking through Drupal modules and documentation looking for solutions to functionality I will need to replicate on the new site.

Solicit Expert: We plan to invite a Drupal consultant to give us feedback on the proposed plan and potentially serve as an "on-call" expert when we need help with the tricker components. We trust in our ability to find a Drupal consultant willing to do this, considering that we contract for time & materials for other pieces of our infrastructure, and open-source consultants may be friendlier than most to being collaborators on a site rather than building the whole thing.

Buy-In: I have built a Drupal clone of some parts of our current web site. Many people judge a web site first by its looks, and this helps take the graphic design out of the consideration of the back-end platform. It helps gain valuable feedback on the viability of the new platform. It also includes the most frequent contributors in the process at an early point.


Which one is the Drupal site?

Design: Assuming that the site passes the other tests, we will then undertake the design in earnest. We will need to spend much time thinking about how best to replicate current site functionality in Drupal. Trying to keep project scope within manageable limits, we will defer considerations of changing the site architecture or graphic design to next year. This will require a much broader consultation within the school community.

Develop: actual configuration of Drupal and additional programming if needed.

Train: Properly prepare site editors for the new editing interface and assist regular users with any aspects that may work differently than before.

Launch: Off with the old, on with the new! I'm unsure whether this will require much external publicity, since we are not changing the look and feel at this time. Internally, we will want to make the transition to the new editing platform as easy as possible especially for those users who only post occasionally.

Your thoughts on this plan?

tags: drupal, webdevelopment, webdesign