Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Changed strikethrough to dashes

...

  1. The evaluation process for software is evolving for college and university campuses from focusing on features (the tools and technologies native to a system, e.g. calendars, file uploads, discussion forums, etc.) to assessing affordances (functionality, i.e. collaboration, communication, etc.).
  2. For obvious reasons, not the least of which is monetary incentive, vendors of academic technologies readily respond to Request for Proposals which includes product descriptions in line with the instruested institution's requirements. Many products do not enjoy direct support from vendors (open source tools such as Bedework, DuraSpace, Drupal, Fedora, Mahara, Moodle, OSP, Sakai, uPortal etc.) or if they do, the vendors may not have the capacity to compete with larger competitors (e.g. Atlassian versus Microsoft, Canonical versus Apple, etc.). Without a vendor to promote a product, and thus respond to formal requests from institutions of higher education, many quality and potentially useful academic technologies go unrecognized. Even with support services for open source options through third party affiliates, these providers may not be interested in a university’s evaluation stage. As such organizations specialize in support and hosting services, there is little incentive to engage with an institution until they have already identified (and thus evaluated) a specific application/technology.
  3. Wiki Markup
    As explained by WCET, "As product features became more common \[nifti:across systems within a product category\], a focus on 'essential questions'  provides more value to educators deciding among competing products." Assessment by campuses is usually based on what it has (its  tools), rather than what a  system enables (its functionality). As different products reach feature parity, a feature-to-feature comparison becomes less valuable.

...

  • enables potential adopters to understand functionality (what the system can do) rather than features (what tools the system has);
  • avoids the never-ending list of sub-features (A discussion forum... that can be sorted by author, date, subject, priority; can be searched; can be exported as a pdf, text, .doc, docx,; can have assessments; has permissions, private, private between author and instructor, private within a group, public to the class, public outside of class, etc. etc. etc. ad nauseum);
  • separates tools from techniques (maybe the best approach to achieve a desired outcome is not through a discussion forum, but through a wiki or blog);
  • extensible across systems and versions ("As a faculty member, I want to create small groups so that students can do peer to peer assessments," will be a teaching and learning practice longer than any technology, e.g. a bulletin board, track changes, discussion forums, wikis, blogs, etc.);
  • addresses multiple teaching and learning styles (there may be various approaches to accomplish a learning activity or objective, that is, one outcome may be achieved using various tools);
  • contributes to training (the same instructions that help evaluators assess the functionality -creating small groups and setting them up to assess each other's work -can be used to train new users and support the help desk as a knowledge base);
  • provides end-user documentation for use (comprehensive knowledge base for the platform- a timely opportunity considering the upcoming release of Sakai 3.0);
  • comprehensiveness (as new teaching and learning scenarios are described and contributed as user stories, they can be used as functional requirements gathering, to not only assess current LMS functionality, but help define future development);
  • creates community (non-technical development session can be offered at conferences to both create user stories and develop and then contribute testing scripts);
  • extends ways to contribute (provide opportunities for current adopters and commercial partners to contribute outside of code development, extending opportunities to campuses and non-technical contributors on those campuses (instructional designers, faculty, even students).

...

Who is responsible for the licensing? How do folks obtain a license?

Resources

nifti:Letter to Sakai Foundation

...