Blog

Meeting minutes 2010-01-20

Welcome aboard Maja!

Maja would like to put together a Catalyst survey with the aim of generating a list of requirements.
  • wiki usage
  • main web site usage
The first draft of the survey will be ready for the next meeting on Feb 1. Everyone should add potential survey questions to the Needs Assessment (put your initials after the addition so Maja knows who to ask when she has questions).

Stacy raised questions about what will happen to the internal web site. Should it be subsumed by the wiki?

Mike proposed a division between wiki and web site: the wiki is "internal", the web site external.

James wants to start moving forward with migration to the new server. Things that need to happen:
  • finish pubcookie installation
  • get PHP source code from Atlas and check it into git repo
  • figure out the URL scheme and directory structures needed to get PHP and Rails to coexist

0 comments

Meeting minutes 2009-11-16

TODOs

  • Set up meeting to discuss site-wide design
  • Set up meeting to discuss portfolios/profiles/archives

Events

  • Submission system (vetted/moderated)
  • Management (google calendar)
  • Display
    • Embedded google calendar
    • Rails template

Portfolios/Archives

  • what types of file formats do we need to support?
  • James, Mike and Stacy to take a first whack at the data model

There needs to be a strong distinction between in-process work and final work.

Wiki

  • How will the wiki be tied into the main site?
  • Course page development and maintenance?

0 comments

Meeting minutes 2009-11-02

  • We're abandoning plans to tie into the UW authentication servers. The technical hurdles are too high.
  • Still looking into wiki history restrictions - a concern for class pages.
  • Start putting together a page of tricks and caveats with respect to the new system (e.g. concerns about history browsing in wiki pages).
  • Help/FAQ pages needed.
  • James to look into dedicated media server.
  • James to look into the correct way to update Apache's httpd.conf file to work with Server Admin.
  • James still to roll out a beta of profile editing onto the wiki.dxarts.washington.edu server - dependent on conifg update methods.
  • Need to include our social media stuff on the web site:
    • Facebook
    • LinkedIn
    • Second Life
  • Billie waiting to put together Catalyst survey until after faculty meeting.

Keep in mind:

  • ADA accessibility
  • Low bandwidth customers

Portfolios/Archives

Stephanie interested in tying Codexa, grad student portfolios, and any other documentation needs together into a centralized system.

Important factors:

  • maintaining (admin side)
  • creating (artist side)
  • consuming (outside viewers)
  • presentation tool
  • archivability

There needs to be a strong distinction between in-process work and final work.

General Wiki Concerns

  • need some kind of site map
  • search
  • glossary with keywords from different categories
  • sprawl control - do we need a wiki czar?

0 comments

Meeting minutes 2009-10-19

  • Rich is still waiting to hear from UW Tech about tying into UW authentication servers.
  • Rich to look into whether there's a developer API for Snow Leopard Wiki Server.
  • Rich to look into wiki history restrictions.
  • James to roll out a beta of profile editing onto the wiki.dxarts.washington.edu server.
  • We'd like to do a presentation on some of the wiki technologies at the next staff meeting.
  • Billie to head up putting together a Catalyst survey on professorial needs for class pages.
  • James to put log file analytics up somewhere for people to peruse.
  • Cynthia to put together requirements docs for course applications.

0 comments

Meeting minutes 2009-09-21

Content Reorganization

It's too early to make any decisions about this. We need more data. We'll start with some log file analysis to determine what content is getting the most attention. Mike to tackle log crunching.

Our primary users are:

  • students
  • staff
  • anonymous users

Billie had offered to help with some information architecture, but she's out of town.

Look and Feel

We basically decided not to mess with look and feel too much at this point. We haven't identified a good in-house designer, which means we might need to look externally. Who did the previous version? How would we go about finding an external designer? Budget?

At this stage we'll apply the current styles to site changes.

The Landing Page

We all want more content on the landing page!

How should we carve up the front page?

  • quick links to frequently accessed content
  • research
  • course info
  • current events

Rich suggested that we might generate the part of the front page from RSS feeds from other parts of the site. This would keep things fresh and current. Rich will look into options here.

Front page management tool options:

  • custom web app
    • most flexible
    • most work
  • Snow Leopard Wiki Server
    • WYSIWYG editing for the masses
    • Fine-grained permissions
    • Federated search
    • Tagging
    • Excellent support for rich media
    • Rich to look into configuration to see is it easy enough to modify the layout to make it as minimalist as possible.
  • blog
    • probably least flexible
    • get some free features such as RSS, keywords, search, plus lots of available plugins to extend functionality

Profiles, Portfolios, Research, Directories

We agreed this screams out for a content management system. This will:

  • force things into a uniform look and feel through templates
  • put users in charge of managing their own content
  • lower barriers to keeping things up to date
  • centralize information in a structured data format for other uses

James H. to tackle.

Course pages

It would be nice to have archiving for course pages, semester over semester. Students would be able to look over previous syllabi to get a feel for course content.

James H. suggested Snow Leopard Wiki Server might be an interesting tool to replace Powerpoint presentations for classes. This would make lecture content immediately available to students. It would streamline the work professors currently have to do with generating and posting PDFs of lecture slides. Permissions could be used to lock down lecture slides not ready for public consumption.

Management tools:

  • wiki
  • straight html with some sort of automatic header/footer wrapper
  • custom web app (probably not ideal since different courses may have different needs)

Archived Content

Max and Stacy will plow ahead with their XML-ification of our archives. For starters, we'll probably publish the data with a simple XML transform which formats the data and wraps it in a header/footer template. As things evolve, we might get more sophisticated with our data storage, slicing and dicing. We discussed developing a database, but decided the benefits were small compared with a straight up XML transform.

Site-wide Federated Search

We need some way to easily search the web site. It should cut across the various web apps, web servers, and bubble up all available content.

  • Full text options
    • Google (e.g. "mechatronics site:www.washington.edu/dxarts OR site:www.dxarts.washington.edu OR site:depts.washington.edu/dxarts")
    • Our own index
      • Nutch
      • Ferret
      • Lucene
  • Piece meal (could be dispatched as separate queries, but combined together in a results page)
    • SQL queries
    • wiki server queries

0 comments