\

So check it out and leave a comment there if you can!

All materials in this wiki are licensed as Creative Commons Attribution Non-Commercial, which means they are free to use by anyone, anywhere, for anything except commercial purposes. We’re proud to be open, especially now, as Instructure opens up the source code of Canvas to the world.

More details available on our wiki site: canvaswiki.uen.org

www.youtube.com/watch?v=dCIP3x5mFmw

A nice homage to Apple--clearly one of Instructure’s design inspirations.

If you didn’t pick it up in the video, this release coincides with Instructure’s announcement that they’ve just opened their source code under the AGPLv3 license.

We just selected Canvas as our State’s LMS here in Utah, and this news only reinforces my opinion that the guys at Instructure are looking a lot farther ahead than anyone else in the LMS business. This isn’t to take any credit away from Moodle, which will always have a special place in my open source heart, but, well, if you haven’t tested Canvas--from either a “traditional” LMS or un-LMS perspective--it’s pretty easy to hop in and give it a test drive.

And now my Canvas package download is done. Expect some installation notes later on.

Many people have their own opinion of what an e-learning platform should be (I spelled out some of my own broad criteria here), but that’s a debate in and of itself that we tried to dodge here. In doing so, we may have taken a number of things for granted–feel free to disagree in the comments. In the mode of keeping it simple, we reviewed Nixty by looking at the following areas:

1. Sign-Up and User Accounts
2. Creating a Course
3. Designing a Course
4. Participating in a Course
5. Conclusion

Sign-Up and Accounts

Signing up for Nixty is a straight forward process via new accounts or Facebook. We didn’t see an OpenID option. Users can populate a contacts list via invitations through Gmail and Yahoo! Mail. Any user can sign up as a learner in any public course, or create a new course and share it with the world.

Within a user’s Settings users can upload a photo or avatar of themselves. Noticeably absent is any field for users’ personal web sites, social network accounts, or Atom/RSS feeds.

Users each have a theme-able “Eportfolio” (see Seth’s at http://nixty.com/eportfolio/Sgur). As opposed to a portfolio that showcases a person’s work, Nixty’s Eportfolio is limited mainly to presenting text information via a resume/CV builder.

Users also have a basic “Blog” (see Jared’s at http://nixty.com/blog/read/jaredstein/). The Nixty Blog allows for rich text editing, but, once submitted, new posts can not be edited. The blogs are publicly visible with no option to make private, either to a single course or to other Nixty members.

Nixty has an internal “Mail” tool which allows messaging of any Nixty user (plain text only). We would have liked to see some sort of integration with external e-mail or social media accounts.

Creating a Course

We began our examination of the features and limitations of Nixty by creating new online courses. In short, creating a new course and adding content is easy. Nixty provides a Wizard, but the interface is simple enough that most users can build courses without it. In most cases Nixty uses AJAX to facilitate page changes without reloading the page.

Courses can be designated as “traditional” or “wiki” versions–the latter allows any Nixty user to edit, add to, or re-order course content. After some confusion, @nixty (via Twitter) let us know that “Tests” and the “Gradebook” features are currently only available in the traditional version.

Course settings allow users to choose a course image icon which appears next to the course in Nixty directories. It also allows the instructor to set learner pass requirements for the course, and even issue a certificate to users upon completion.

The core unit of a Nixty course is the “Lesson” folder. Lesson folders can have learner instructions, can be nested, and can contain a sequence of any number of “Content” materials, “Discussions”, or “Tests”. Content is typically embedded HTML, but can also be a document (e.g. PDF or DOC), a media file, etc. We saw no way to scrape content from a web page–blog, wiki, or other. Also, though labeled “wiki” the wiki version of a course offers few wiki-like features, such as easy creation of new pages, access to wiki mark-up, version histories, etc.

The usability of the Content embedder/editor varied over the two days we used Nixty. Sometimes a simply WYSIWYG editor popped right up; sometimes the editor window was too small to use; sometimes it failed altogether with no error message.

Nixty allows for media uploads, though they recommend use of YouTube for videos. This is surely done for space/bandwidth reasons, but to us it’s the sort of behavior that should be encouraged throughout the system: designers (and users) should host their own materials in the cloud (Flickr, YouTube, Wikibooks, etc), and simple embed that content into the system’s framework.

Reordering Lesson folders was a bit painful. Initial ordering forces the creator to assign a number to each item. However, new items are not automatically queued to the next number, but have to be manually numbered through Manage Course > Lessons > Order Folders.

In our testing the “Syllabus” builder appeared to simply be broken, but there are obvious work-arounds, e.g. syllabus as an external file, or embed it as Content in a Lesson folder.

“Tests” can be used for exams or quizzes, and allow for basic multiple choice, true/false, multiple answer, fill in the blank, ordering and essay questions. Tests showed no option for question categories, pools, or randomization. Remember: Tests are only available in “traditional” version courses.

The “Gradebook” only allows for a Pass/Fail point-value cutoff. A clear limitation for most conventional instructors. Again, the Gradebook is only available in “traditional” version courses.

“Discussions” use the term “thread” but are not actually reply-threaded as we expected.

Nixty has neither an import nor export option for courses or materials, making migration to or from laborious.

Despite Nixty’s apparent draw for opencourseware and open educational resource projects, Nixty provides no licensing feature for content. We expected to be able to list license properties for individual items similar to Flickr, educommons, or the Moodle OpenShare mod.

We can’t discuss the course creation/development process without mentioning the navigation on the web site. Navigation is inconsistent at best, and often laborious or confusing. The following video illustrates one example that’s sure frustrate instructors in number of clicks alone:

(Note: I am aware that this screencast is not scaling properly.)
[kml_flashembed movie="http://5tein.com/media/video/nixty-edit-content.swf" scale="exactfit" height="300" width="400" /]

Once finished, a creator can make a course public–this lists the course in the Nixty directory and allows other users to sign up for the course.

Designing a Course

We’ve looked at the nuts and bolts of Nixty in order to experience the possibilities, though actually designing a course is a different matter. Design of a successful informal or open course depends a lot on the limitations and affordances of a given system, the creativity of the designer, and the needs of the learners–an element apparently overlooked by Nixty (and most other LMS). We examined design considerations by looking at adapting my own online course, and examining a few of the spotlighted courses in Nixty.

The course I built in Nixty is based on my existing fully online 3-credit course, which aims to lay the groundwork for new web developers by introducing the basics of XHTML and CSS. The course design is a fairly traditional: primarily linear experience that connects heavily project-based instructional lessons with weekly discussions, journals, and learning quizzes.

(As with any conversion or migration, I had the bitter-sweet realization that my course had flaws scars that I was not quite ready to make public. This does, however, encourage me to make improvements under possible public scrutiny.)

In my course Because there is no built-in assignment tool designers have to rely on Discussions and Tests for activities. I did insert assignments into his Nixty course, and conforming to the nature of the informal, open educational experience I listed them as self-assessment only. And though I did provide a basic scoring criteria list, a better self-assessment feature would allow instructors to create rubrics, and users to score and track their work. Assignment-type activities would also be bolstered by a simple URL submission field, or even linking to artifacts in a learner’s Eportfolio (though the Eportfolio does not support objects/artifacts).

Use of essay-type questions in Tests could accommodate non-standard activities and assessments, but I think for such an option to thrive in an informal experience peer users would need to be able to access other learners’ quiz results for feedback and scoring. Wouldn’t that be interesting?

Alternatively, a Discussion could be used for project submission and peer feedback. Because file upload is not an option, learners would have to refer to files hosted elsewhere. This limitation may in fact encourage better practices in learners, as each would have to have their own space(s) on the web for publishing educational and professional artifacts (e.g. a blog, Flickr, Slideshare, etc). Unfortunately, the designer’s Discussion thread creation prompt does not provide anything more than a plain text editor, limiting the richness of instructions for the learners.

In my Nixty course, as in most courses, the structure is fairly limited and contained by the Lesson folders, which contain only linearly-sequenced Content, Discussions, etc. The following short video shows how OCW_Maven structured OCW-based courses by interspersing Content and Q&A Discussions:

(Note: I am aware that this screencast is not scaling properly.)
[kml_flashembed movie="http://5tein.com/media/video/nixty-discussions-lesson.swf" scale="exactfit" height="300" width="400" /]

In our opinion a truly disruptive educational platform should encourage alternative structures, including recursive sequencing, e.g. learning branches or paths. That Nixty provides a “wiki” option for the course suggests a highly organic possibility, yet as mentioned several key wiki features are absent, especially dynamic, on-the-fly creation of new pages from links.

Participating in a Course

The idea behind a formally informal course experience is that a critical mass of users congregate around a learning hub in order to provide peer-to-peer or expert-to-peer feedback, direction, or mentoring. This requires a large number of users active on the site. It also requires a method of connecting users with the site’s activities when they are away from the course. Often this is done via e-mail, but the simple–yet surprisingly rare–method is with Atom or RSS feeds, for either content updates or discussion threads. Nixty provides neither feature, which may be the single largest weakness threatening the success of a project that apparently aims to be an open, informal learning hub.

Tests aside, “completion” of a Lesson, Discussion, or piece of content is based primarily on the user clicking “Mark this item complete”. This is fine for monitoring simple progress through a sequence of activities, but provides no real feedback to users on more substantive levels of progress. We suggested previously that a self-assessment rubric and tracking feature would be ideal for projects and assignments. Further, a reflective journaling field could be employed to help users track their thoughts as they progress through the materials.

Discussion responses can be voted “up” or “down”, but we thought that a better user feedback feature would provide additional, aggregable feedback to users in cases where the Discussion is used for sharing of work and solicitation of critiques. Users replying to a thread can use a GUI editor to compose their responses, but can not attach files. Again, this is not necessary with a PLE/PLN-informed perspective on digital identities and self-publishing, but many instructors–and learners–will look for this.

A plus for anyone planning to try Nixty is the fact that their representatives are very active on the support forums as well as on Twitter, and are more than willing to engage the community, answer questions, and offer advice.

Conclusion

As a simple e-learning platform Nixty is fairly satisfying. It’s willingness to provide a home for discussing and organizing content is laudable, and its aim to provide an alternative, open platform for informal learning is something we’ve been talking about for years.

The version of Nixty reviewed here is somewhat promising for informal learning scenarios, and the lightweight nature of the LMS can, at times, feel like a breath of fresh air over heavier LMS. The shifted paradigm of the system and its inherent limitations may encourage designers and educators to think about informal and independent learning in alternate ways.

However, broken or absent features make it difficult to recommend as a serious e-learning platform or an LMS. Indeed, existing Web 2.0 systems–either independently or in tandem–offer better core functionality (e.g. WordPress, MediaWiki), and we can think of other specifically educational platforms that would probably serve as well or better. For instance, the commercial LMS provider Instructure offers free individual course accounts to instructors as well as a public course option for informal open courses. Instructure Canvas is a more mature and feature-rich LMS platform that should not be ignored by open educators and educational theorists. And, of course, open source-minded folks would can just host their own instance Moodle or Sakai. (It’s somewhat surprising that Nixty didn’t build itself on either of these platforms, which are also full-featured and more mature.)

The fact that Nixty is new forces something of a catch-22: many self-directed learners and open educators won’t want to invest the time in using it until a critical mass of users can support those experiences; yet not critical mass is possible without users committing the system.

Despite its weaknesses Nixty is an interesting project, and we’ll be watching as its development progresses in the coming months and years. At this stage at least, Nixty is missing too many features, exhibits too many bugs, and offers little new affordances for us to encourage its adoption at this stage for anything except experimental open educational experiences.

Now like the iPhone/Touch the iPad can use thousands of “apps”– miniature applications developed solely for use on iPhone/iTouch/iPad, and sold through the Apple store. What’s always been disconcerting about the app development process is that Apple controls not only the specifications for apps, but also restricts what apps are made available for use on their product, censors content, and even denies what technologies can be used to produce such apps.

Apple has the right to do all this, of course–it’s their device. Even though the approach out-M$s Microsoft, Apple’s restrictions on production and content of the apps is only one side of a larger problem. What really concerns me is how Apple’s app model will impact digital content on the open web, and I’m not talking about Flash.

The Web as an App

We’ve seen already a number of apps that replicate core functionality of web sites. We’re starting to see more apps produced by content providers as a supplement to their existing web-based content (e.g. Wired, NPR, WSJ). But how long until this supplement supplants the web-based stream? How long until consumers are hooked into fee-based access to this content under the illusion that it’s only available through the app?
I believe Apple has been rather insidious, if clever, in their iPhone/iPad app model, wherein the closed nature of their system requires a kind of fake innovation in the development of “new” apps that do little more than their web-based cousins; certainly little more than what’s already possible with a web browser and a little creative use of standards-based web languages. Instead, these appear to be little more than an opportunity for approved providers to elicit fees in new ways from end-users.

Don’t get me wrong: I’m all for businesses finding new ways to make money by improving service or a product, but is that what we are getting here? The drive to develop web-based products as apps seems entirely backwards, for we already have the one tool we need to facilitate mobility of both content and services: the standards-compliant web browser. What technologies do we need? Not C, C++, or even Flash, but how about HTML, CSS, Javascript, XML, and PHP? How about the open web standards that have facilitated the information access revolution we are experiencing?

Now a “special” path to mobile device development is nothing new; even the W3 tried to sell us on HDML rather than alternative CSS and minimalistic but semantically correct XHTML. But I think time has proven that this is wasted effort in the face of a broadly-accepted, dually-purposed web site constructed on sound principles of web design and utilizing creative applications of open technologies. Even NPR seems to prove this point by the fact that it has not only released it’s own iPad app, it’s also reworked it’s web site to be “iPad-friendly” for those who don’t want to download the (free) app. And at first glance it looks like the web site provides the same essential features.

Enter Blackboard

As expected, in an attempt to capitalize on the iPad buzz and finally make good on years of broken promises for mobile accessibility, Blackboard has unveiled its iPad app, which

recreates the course experience of Blackboard Learn™ … and lets students check grades and assignments, add discussion board comments and blog posts, email instructors and classmates

How stunningly innovative! I surely couldn’t do any of that on a mobile web browser?

I probably rehash this example too often, but I remember sitting in a session at a WebCT conference 5 years ago that was supposed to reveal WebCT’s innovations in mobile delivery of content. Turned out the WebCT rep had nothing to share, but hoped to take ideas from the audience. Disappointed, I turned to my Palm Treo phone and did some grading through Blazer on Moodle. Though the HTML, CSS, and Javascript of Moodle was still disappointingly primitive at the time, it was just good enough that the weak Blazer browser could handle it, and demonstrated the power of using open web standards.

Michael Feldstein suggests that this sort of “innovation” will promote the iPad itself, saying, “if I were a student or faculty member heavily using Blackboard and thinking about buying an iPad, I might find this app to be an additional motivator to buy one”. I bet Bb is hoping the reverse of this will be true: that by providing all their students with an iPad colleges like Seton Hill and George Fox will create a scenario that fits just right with their particular e-learning solution, which is “the industry leader” with full support for “mobile devices”.

This restrictive piping of information that we currently take for granted on the open web is of greatest concern to educators, perhaps, because it has the potential to retard the development of new models of learning. I don’t mean “learning by doing”, though iPad’s failure to support creative production is notable (Jeff Jarvis writes, “It turns us back into an audience again”); I mean particularly developing models that encourage increased learner self-regulation and networked direction along variable learning paths. Such models require access–both broad and deep–to information and depend upon content aggregation, parsing, and re-dissemination. These capabilities have only recently begun to be realized through the open web, thanks in large part to web standards. What schism might the apps model cause in this new standard of information accessibility? What locks and limitations may now encrust upon the ideals of the open web?

However, dP is not without its flaws; indeed, I became so frustrated that late last week I asked my lead developer Ken Woodward to send me some examples of competitive systems that did not include BaseCamp. While BaseCamp is a great system, and probably amongst the top few project management tools out there, it’s not cheap, and we have a lot of projects running simultaneously. Plus, I am a constant advocate of OSS solutions, and in this situation, where many of my staff are student developers, having a locally-owned OSS platform that can be modified by my staff as they learn their trade is very attractive.

Let me note that I always feel guilty critiquing an OSS project, especially when I myself haven’t made any significant contributions to the code. At the same time, with increasing competition in OSS solutions, one has more liberty to leave behind that which doesn’t suit one’s needs. Further, reasonable explication of the features and failures of any system is valuable to developers who are committed to building and maintaining a quality system. So here’s a quick review of dotProject with some particular attention to the broken bits. My next post will introduce the alternatives that we are considering.

Here’s a list of dP’s strengths or notable features:

• user-based and password protected
• email integrated
• distinction between projects and tasks (you’d be surprised how many “project management” tools omit this!)
• robust data at the project level, with good hierarchical layout of tasks
• project tasks may be imported into other projects, thus “templates”
• calendaring
• task dependency
• good, flexible task logging and time tracking
• decent gant charts
• written in PHP
• themes

Now, a list of complaints:

No RSS. For my unit, RSS or Atom feeds are taken for granted. If I can’t put my task list on my Google home page, I’m not happy. RSS is easy to script, however, so we could add this feature to our To Do list.

Inconsistent task/to do list. I haven’t quite figured this out, but one’s “tasks” list is different from the “to do” list that dP presents. This appears to just be a bug, as the To Do list–which is actually harder to get to–is more accurate.

Some weird PHP scripting. For instance, project categories: one can create categories for projects, like “in planning” or “in progress” or “pilot” or “complete”. The problem seems to be that dP attaches a simple numeric id to each of these category names. It attaches the same numeric id to the projects in the category. Makes sense, right? Wrong. The category ids correspond to the order in which they appear as tabs in the dP interface; if you change the order, the numeric ids of the categories change, and thus no longer match the project categories. I’ve actually found several examples of similarly breakable scripting in the system (including a stubborn “masking” of certain projects related to this) but this was the most frustrating one.

Calendar/date entry is inadequate. In order to set a task due date to, say, December 2010, you can’t type 12/01/2010, you have to open the calendar GUI, then click, click, click, click through the months until you get to December 2010.

Little data available outside of gant charts. And the gant charts fail to react intelligently to clearly “inactive” projects, instead extending them perpetually as if someone were still working on it (even though no hours were logged). But really the main complaint here is that there is no simple, easy way to access data on staff or projects. For example, I can’t click a user’s name and determine how many hours they logged in dP this week. I can’t look at all projects of a type and get an average of hours spent to completion. I can get clear, individual project data from individual projects

Not embeddable, widgetizeable. Several project management systems have scripts, or embeddable widgets, or even desktop apps that help you monitor your tasks. dP does not yet. If they only had RSS, we’d be able to get somewhere. XML RPC? That’d be cool.

Average GUI. The graphical user interface in dP is average at best. It’s not horrible; it’s not elegant. It could be adjusted with a new CSS, but my experimentation with theming in dP is that too much can go wrong, and I’ve tried several themes that actually break basic features of the system! OK, so maybe I just need to spend more time on this, but compared to theming in Drupal or WordPress, dP theming is no fun.

Small community support. Though the quality of people involved in dP is great, the number of people developing, contributing, and using the system is a lot smaller than I’d hoped for. The last date of a major upgrade or bug fix was July 2008. I really want to add some of my staff to that community, but right now may not be the best time in the history of our organization.

So, we’re looking at other options–and I’ll review some of those next time–but I recognize that in the end we may stick with dP. If we do, it will have to be with a greater commitment to participate in the dP community, because several of these complaints I’ve listed simply can’t be allowed to stand, and its true we haven’t given much back.

On Thursday I shared an hour with Terri Rowenhorst of NROC introducing folks at WCET 2009 to open education and some of the ideas and directions orbiting around it. Mine was just a half-hour pres, and didn’t get into some of the meatier bits that interest me; nonetheless the slides and video may be of interest:

• “Openness as a Catalyst for Education” slides on SlideShare
• “Openness as a Catalyst for Education” video on ustream

You may have already heard some of the Twitter buzz about Chris Lott‘s presentation, “Closing the Gutenberg Parenthesis”, so here are links to his slides, video, and wiki:

• “Closing the Gutenberg Parenthesis” video on ustream
• “Closing the Gutenberg Parenthesis” slides on SlideShare
• “Closing the Gutenberg Parenthesis” wiki with matrix

Chris let me moderate this session, and it was exciting to monitor the backchannels on Twitter and ustream for questions, ideas, or challenges that I could interrupt him with. As always, Chris did a fabulous job presenting a continual stream of rich ideas on technology and learning. I must admit I may have underestimated both Chris and the WCET audience prior to the session; both seemed quite comfortable with complex and provocative notions embedded in our connected culture and interplaying with Ong’s concept of a “secondary orality”.

It was a gorgeously sweet-smelling rainy day, but I managed to bring
myself into the confines of a BYU classroom to attend David
Wiley's IPT 692R: Intro to Open Education. Today we're looking
at how an institution, BYU in particular, might approach institutional
policy and practice supportive of open licensing of teaching materials
and research publications. The conversation was shaped by
the context of MIT's model for both OCW and
open access.

Besides institutional pressure, what are incentives for faculty to opt
in (open licensing of teaching materials)?

• For BYU, incentive may be scriptural/doctrinal imperative to share
• Tap into the motivation to Do Good (Is it true that BYU fac/staff
  make _less_ than other institutions? To me, BYU seems so
  well-funded, and in some instances over-funded.)
• dissemination, reputation

Technology and Support Issues

Technology

• what system
• who pays
• who manages/hosts?

Support

• Who trains faculty, staff?
• Depositing where?
• Who pays?

• Source
  

• Who?

Concluding Thoughts and Questions

Justin: We need a raison d'etre. we do this as an
institutional community because…

Aaron: Do we anticipate a change in structure to facilitate and
support openness?

Dr. Wiley: We need to fully consider existing systems and see how they
might pipe in. Syllabus Builder, Learning Outcomes wiki

Dr. W: Should we require open syllabi? Institutional IP policy says
faculty own it; but institution would step in and claim nonexclusive
right to redistribute.

John: Sounds harsh. If you require me to, that strips away my agency.

JMS: That's agreed, but from a student-centered focus argument for
it wins.

Dr. W: We should argue that open is good because of pragmatic reasons,
not openness for the sake of openness. We'll have recommendations
for teaching practice (e.g. cost of textbooks, availability of open
resources)

Aaron: What are conflicts of interest?

Dr. W: Can't require students to adopt your textbook unless
you're selling more copies off-campus than on-campus.

Justin: For pragmatic reasons it makes sense to model our policies on
the successful approaches of other institutions, for example, MIT. No
need to be different just to be different.

Dr. W: Use our repository OR go your own way.

I mean, of course, with respect to appropriately licensed (Creative Commons, Gnu Free Document License, etc) open educational resources specifically.

And though the question is not staggering, it may be taken for granted, even at the cost of the long-term success of the web project.

Linking

The link approach typically uses hyperlinks to the target source document, but may use iframes to embed the element within a locally-hosted web page.

Linking…

1. preserves integrity of the original source by maintaining all original qualities
2. respects original source by trajecting traffic to the host site
3. saves local hosting resources (storage & bandwith)
4. ensures that source updates are reflected in the current version
5. is, therefore, particularly well-suited for frequently updated or improved sources, like wikis
6. is much easier, particularly when numerous multimedia files are embedded, or multiple files are referenced
7. may provide learners with context and hyperlinks that lead to further, relevant exploration of the source site and the web
8. avoids problems with licenses or terms of use that restrict copying

Many of these arguments for linking presume that there is more to the information than the information itself, and that the source has some inherent value that may be passed on to the learners or should be maintained for its own sake.

Copying

The copy approach is similarly self-evident: a digital copy of the source file(s) is downloaded, then hosted on the local server.

Copying…

1. provides for adaptation or modification (if the license allows) of:
   • content (cut, insert, remix, extend)
   • presentation (e.g. surface design)
   • interactions
2. supports localization
3. captures and preserves a version that may be discarded or replaced in the future
4. allows designers to produce seamless learning experiences that support learner focus
5. respects original source host’s resources (storage & bandwith)
6. ensures technical availability of the resource is within local control (no dead links)
7. allows contextual indexing for site (or public) search engines
8. may improve reach and increase circulation of source information
9. may thereby enlarge original author’s prominence and visibility
10. avoids problems with licenses or terms of use that restrict leech-linking

A couple notable obstacles to copying:

• Server-generated content, markup, interactions, or hyperlinks may be difficult to acquire or reuse (e.g.
• While CC By-ND allows reproduction of works, it may restrict modification of presentation or interactions in addition to the more clear prohibition on modification of content

Dynamic Scraping and Importing

There are other approaches that fall somewhere in between. For instance, web scraping of the source file(s) on the fly, followed by parsing and processing of the data on the local host. This sounds complex, but it’s not too bad; Google Docs & Spreadsheets has implemented this functionality into it’s data importing spreadsheet formulae:

• =importHTML grabs the content of a TABLE or list (OL / UL [/DL?])
• =importXML uses xPath expressions to target XML/XHTML elements
• =importData takes structured data files, such as comma separated values (CSV)
• =GoogleReader intakes the RSS or Atom of a target URL, such as a blog post

Often used for mash-ups, this approach can also be useful for replicating and formatting data. And, though Tony Hirst has found numerous exemplary applications for this feature using Google Spreadsheets, a Google Spreadsheet is not required; anyone with some significant Javascript experience could tackle this task, and there are a number of web scraping software apps that deliver varying results.