K-12 Teaching and Learning From the UNC School of Education

Important Announcement about Online Courses and LEARN NC.

Important Message about LEARN NC

LEARN NC is evaluating its role in the current online education environment as it relates directly to the mission of UNC-Chapel Hill School of Education (UNC-CH SOE). We plan to look at our ability to facilitate the transmission of the best research coming out of UNC-CH SOE and other campus partners to support classroom teachers across North Carolina. We will begin by evaluating our existing faculty and student involvement with various NC public schools to determine what might be useful to share with you.

Don’t worry! The lesson plans, articles, and textbooks you use and love aren’t going away. They are simply being moved into the new LEARN NC Digital Archive. While we are moving away from a focus on publishing, we know it’s important that educators have access to these kinds of resources. These resources will be preserved on our website for the foreseeable future. That said, we’re directing our resources into our newest efforts, so we won’t be adding to the archive or updating its contents. This means that as the North Carolina Standard Course of Study changes in the future, we won’t be re-aligning resources. Our full-text and tag searches should make it possible for you to find exactly what you need, regardless of standards alignment.

This is an overview of the web application framework, called "Lighthouse", that was developed by LEARN as part of our website refresh initiative.

Getting Around

A good starting point is to think about Lighthouse as a video game console, and individual "apps" as games. Lighthouse allows apps to be played, one at a time, inside a common HTML frame. This is how you ask Lighthouse to play an app:

www.example.com/?app [try example]

When an app is requested as above, without any other qualification, it will appear in an initial mode called the default "state". A state is simply an application mode that the developer chooses to make accessible via URL. You can request a particular state as follows:

www.example.com/?app=state [try example]

Apps musth be capable of reporting defined states to the framework, allowing Lighthouse to create a sitemap file containing all possible URLs in a given installation:

www.example.com/?sitemap [try example] requires password - ask John

Request Lifecycle

To get an idea how this all works, suppose a user makes a typical request:

www.example.com/?app=state

First the app will create a simple view of the requested content, called a "snapshot". This snapshot is embedded in a HTML frame which is shared across all Lighthouse apps.

Now the server returns the framed snapshot to the client, which could be any flavor of browser or search engine bot. What happens next depends on what capabilities the client has or wants to employ. Lighthouse presents the client with two options: take the snapshot as it is, or execute javascript to enhance the view.

If the latter option is chosen, Lighthouse flushes the content and replaces it with the enhanced version. Furthermore, assuming the client supports HTML5 pushState, the Lighthouse lifecycle moves to be client-centric rather than server-centric for the remainder of the session. This means that when the user navigates to a new URL within the same Lighthouse instance, rather than being sent to the server, the request is intercepted by the client which performs its own update by loading javascript resources as they become needed.

Lighthouse Request Lifecycle
Test