Unlike printed text, human thought is highly nonlinear. While a textbook plods along from introduction to details to examples to conclusion, a student's mind darts between the general and the specific, from one new term to another, building abstraction upon abstraction. Perhaps a student is familiar with certain material in a text but not with other material; currently he or she must skim the known material, being careful not to miss ideas crucial to the unkown material. It is time for electronic text to break from its printed cousin, to adapt to the way people work, not paper. The term adaptive content
describes a framework for presenting and manipulating text and images. Here are a few examples of what this framework will allow: one can
- choose what content appears
- ask questions pertinent to specific content
- look up terms in a search-as-you-type environment, like at the top of this page
- add labels, or tags, to content for future reference.
- search through content seen before
- search content semantically (e.g. find content with the tag "philosophy" or "golf")
Picking and Choosing Content
Different students should see different parts of any given content, based on factors including personal preferences, learning style, knowledge, and purpose. While the ultimate goal is to profile students perfectly and show them exactly the content they need to see, the current [resonable] goal is to make a good generalized guess and then let students tweak the results. While perusing content, a student will often switch between looking at the overview and the gory details, emphasize or deemphasize terms, search for related material. This level of interaction drives the need for a fluid experience, based on content that can be dynamically altered without distracting page-reloads, an artifact of obsolete Internet standards.
A very simplistic approach might involve defining each piece of some content as either "introduction", "detail", or "summary". To get an overview of the content, a student would hide all text marked "detail". While this approach would be useful, it is limited and fixed. It is much more desirable to have a method for arbitrarily describing sections and subsections of text, allowing the student both broad and fine control over display and format. Students could ask questions about one paragraph, bookmark a section for later reading, and hide detailed discussion about a certain topic. The possibilities are close to endless.
An Example Interface
Imagine that there are are a series of virtual bins
, or boxes, adjacent to this text: "hide", "show similar content", "save for later reading", "ask a question". You can click and drag paragraphs, lists, images, and such to these bins in order to perform actions on them. Access to what you have dragged to the bins is only a click away; undoing actions is a matter of clicking the "back" button. The options to view or reset all page content are clear and easy to understand. It feels natural to completely control the content in front of you, as if that is how it always should have been.
Technical Overviewthe following content needs editing and is not required to understand the main idea
Due to the nature of HTML, content must be presented in a hierarchical manner (think DOM
). Sections and subsections contain overview text, detailed text, code examples, etc. Students must be allowed to target HTML tags described with metadata, employing both hierarchical and non-hierarchical methods. The logical solution is to place metadata tags in
attributes and use CSS selectors to target these tags
Some HTML tags should be uniquely identifiable, while some should not. A good question to ask is, "is there any reason to target this very specific element?" Remember that there are different operations that can be performed on content. It does not make sense to hide a single word in a paragraph, while it does make sense to hide a whole paragraph. Operations that should be performed on a single word level include coloring all term tags a certain color; such actiona do not require unique identifiers. Block-level tags seem to be a good cutoff: anything block-level should be uniquely identifiable, while anything not block-level should not.
Another concern for unique identification is ID rot, when a pointer to an ID becomes invalid due to structural or data modifications. As much as is reasonable, unique IDs should survive small to moderate content updates; we would rather small changes to text not invalidate CSS rules a student "owns". Again, block-level tags seem to be a good cutoff.
Content is stored in a database with a rougher granularity than block-level tags. Moderate content changes should rarely leave a single storage "unit". Sections are prone to having their paragraphs reworked, so storage units will often span multiple paragraphs. Because lists will often get changed, they should also be storage units. Storage units should be kept small enough that their content has the potential to be portable; it would be nice to use the same code example in two different tutorials.
There are actually two kinds of relevant database records: one that contains content, and one that aggregates content.
s would represent content, while
s would represent "aggregators". When reasonable, it should be possible to have two aggregators touch some of the same content. Both content records and aggregator records will have unique IDs; one beauty of this system is that students can be notified immediately if they have seen the same content or the same aggregator in a different tutorial. The price (boring students) of being repetative suddently vanishes, as students can choose to hide or somehow diminish content they have already seen.
What remains is to determine how hiding/showing content works. We want elegant methods for displaying where content is hidden, as well as ways to unhide content. While dragging to a bin might be one way to hide content, we probably want alternatives that require less work than a drag. This should be sufficient to setup a realistic prototype.
Let us return to the bin concept discussed above, where students drag pieces of text to one of several bins. Things get tricky with containers, such as
s: do we only allow students to drag entire
s, or do we also let them drag
s? How do we differentiate which is being dragged? One option is to use the state of the ALT key to determine whether a container's child is dragged or the container itself. If we want to get more complicated, we could allow the + and – keys to control whether child or container get dragged.
The code example below is currently being worked on.
<p><span>This would be the first sentence.</span><span>The rest of
<p>This is another paragraph, which should be hidden if only the
first sentence of the above paragraph is visible.</p>
<h5>A subsection</h5>[click to collapse]
<p><span>This is another first sentence.</span><span> Followed
by more content. Note that the following paragraphs are
<h5>A mostly-hidden subsection</h5>
<p><span>The first sentence is all that shows</span>
<h5>A completely hidden subsection</h5>[click to expand]
Here is an in-progress demo
(note: it doesn't quite seem to be functioning at the moment).