Forum .LRN Q&A: Curriculum Phase 1

Collapse
1: Curriculum Phase 1
Posted by Carl Robert Blesius on 02/28/03 01:49 AM
Ola has put up a demo of the old (OpenACS 3.2.5) curriculum package as well as a preliminary mockup for the new curriculum package.  https://openacs.org/projects/dotlrn/dotlrn-enhancments/curriculum/

The old curriculum progress bar is not prominent enough and it disappears when you go off site. I am not a fan of frames, but this seems like the curriculum package might be good place to use them (the "progress bar" could be at the top of every page in a curriculum sequence regardless of where the subject matter is located). Something like what About.com does for external links -> http://arthistory.about.com/gi/dynamic/offsite.htm?site=http://www2.mmlc.nwu.edu/c303/levavy/introduction.html (in our case it would not be for banner adds but curriculum feedback and interaction).

Any other ideas, comments, use cases? Ola and Staffan are getting ready to start Phase 1 of the curriculum project and some feedback would be nice before they get started.

Collapse
2: Re: Curriculum Phase 1 (response to 1)
Posted by Don Baccus on 02/28/03 02:48 AM
Please, no frames in standard toolkit pieces, which I presume this is destined to become.

The site you refer to is pretty ugly with the top frame - I get a scroll bar in the bottom one and its "frame-ed-ness" is immediately obvious.  It can be better hidden, of course, but we really want to avoid frames unless there's a compelling reason to use them.

(the CMS started life as a standalone system and Karl Goldstein probably used frames because he had to do everything differently than was done in the ACS - if ACS 4.0 had been framed then he probably wouldn't've used them in the CMS!)

You don't really want to dictate layout struture to users of such a facility.  There will be portlets and applets for dotLRN that can be shoved around by users on their own page.

Ola et al can also supply an includable panel that could be run across the top of the page by a [sub]site's custom master template.  Or at the bottom of the page.  Or in the middle of the page.  Or wherever the *site designer*, not the *package implementor* chooses.

(the portlet in turn can just include the includable panel after grabbing some basic portlet values that tell it whether or not to actually display itself, etc)

Collapse
3: Re: Curriculum Phase 1 (response to 1)
Posted by Don Baccus on 02/28/03 02:53 AM
Oh ... don't let my comments make you think I'm not happy about this project, I think it's great!

And Polyxena's website's pretty classy ... I like the flag favicon, too.

Collapse
4: Re: Curriculum Phase 1 (response to 2)
Posted by Carl Robert Blesius on 02/28/03 09:22 AM
About.com was not a good example Don, it was just the first one that came to mind. My suggestion is limited to external sites, where including content inline would be difficult at best. I know that we do not need (and shouldn't use) frames locally, but we need to have some way of "hanging around" while our students absorb external content so we can share and collect info from them. Frames would just be one way of doing it. Other ideas?
Collapse
5: Why not use popups? (response to 1)
Posted by Malte Sussdorff on 02/28/03 09:32 AM
I know it might be annoying, but for every external content we could use them. I imagine that content is not only limited to websites but also to Files, Movie Streams, whatever you can think of. And if you download a word document, MS Word or Staroffice will popup anyway as well.

Alternatively, at least for all html code, we could fetch the HTML source, strip the header and footer away and just display the body with the curriculum bar added to the buttom.

Collapse
6: Re: Curriculum Phase 1 (response to 1)
Posted by Michael Feldstein on 02/28/03 02:22 PM
First, I agree that this is a piece that you want to make available as a template bit that designers can place anywhere on the page. I don't really have a sense of how easy templates and portlets are for typical page designers to use at this point, but I would think that making it easier for them to move things around on their own is a priority.

A few thoughts:

- The current design of check boxes won't scale. What if your course is 25 pages?

- What the progress bar currently represents is a table of contents plus visual indicators of what you've seen on that table of contents. We use a device like this all the time in our courses, usually in the form of an always-visible left-side menu. I would suggest that you represent this data in an easily retreivable data format (e.g., XML) that designers can use to draw whatever visual representation pleases them.

- Another common form of progress bar in online courses scales by omiting page titles. Page counters (e.g., "page 3 of 15") and literal progress *bars* that show you a visual representation of the percentage of task done.

- If you do separate data from presentation in a way that's easily manipulated by page designers then it would be nice to include several sample templates. Definitely more than one.

- While I agree with Don that frames is a bad idea, I wouldn't mind seeing at least one template use layers to do the same thing (provided that we also include at least one template that sticks with least common denominator technology). Layers is the right way to do what Carl has in mind and not all owners of these systems will be reluctant to specify 4.x browers or above (or even 6.x browsers or above).

Collapse
7: Re: Curriculum Phase 1 (response to 1)
Posted by Dave Bauer on 02/28/03 02:39 PM
Michael,

I think an better representation of data that can be manipulated in a template in OpenACS is a multirow datasource. XML is good for exchanging data between systems (as one of many possible inerchange formats), but for use within OpenACS it is not really necessary.

Collapse
8: Re: Curriculum Phase 1 (response to 1)
Posted by Dave Bauer on 02/28/03 02:45 PM
I really think a left (or right) vertical process bar would be easier to view with anything that has more than 2 or 3 steps. The templating wizard function does this pretty well right now.
Collapse
9: Re: Curriculum Phase 1 (response to 1)
Posted by Michael Feldstein on 02/28/03 04:44 PM
Dave, I'm certainly the last person to be taken as the authority on implementation. However, FWIW, SCORM and Simple Sequencing envision courses as client-side packages that are independent of the back end. Typically (though not always), the course content would be developed entirely in client-side technologies independent of an LMS and then imported into the system. The LMS (in theory, though often not in practice yet) would gather the content structure from the course's SCORM manifest (which is an XML document) and generate the navigation. So, since externally developed course packages that use SCORM (which, I understand, will eventually interoperate with curriculum) will need to deal with XML for navigation generation anyway, it might be a good idea to look at the implementation from this perspective.
Collapse
10: Comments on initial curriculum feedback (response to 1)
Posted by Ola Hansson on 02/28/03 05:14 PM
Just like Dave I think the templating system's multirow datasource is very good when it comes to representing the data we want to process, render, etc. We then have several useful templating tags at our disposal, such as; <multiple>, <group> and <grid>. Beside the standard <multiple>, <group> lets us ,umm, group "bars", thus making it possible to distinguish the courses. The <grid> tag might be useful if we want to tell the bar that under no circumstances should it become more than N columns whide for instance. This could be a package instance parameter or, in the future, a personal setting (user preference). Even if we limit the number of columns in a (horizontal) bar there could still be problems with sideways scrolling if the element links are long, though ...

As Michael says, there could be a host of bar templates to choose from - horizontal as well as vertical - that could be <include>d. Either that or an automatically assigned @curriculum_bar@ variable in the subsite's default master that is either set to *the bar* or the empty string depending on whether the curriculum package is installed or not (as in the case with the "developer support" stuff). The site implementor should be able to place the bar wherever (s)he likes, like Don also said.

Malte, when you say popups I presume you are talking about the "target" attribute of the "a" html tag, opening a new window, right? This sounds like a pretty good alternative to using frames, IMHO, especially taking into account the profound dislike of frames I know this community (including myself) has expressed time and time again ...

Dave, I will look at the templating wizard. If you know of some example code, feel free to point me to it.

Thanks for the excellent feedback, guys, and keep it coming!

Collapse
12: Re: Curriculum Phase 1 (response to 1)
Posted by Michael Feldstein on 02/28/03 06:02 PM
Please do keep in mind that Philip didn't invent the course progress indicator widget. Many, many, many courses implement different forms of progress indicators. Chances are good that potential users of dotLRN will be well aware of these conventions and will have well-developed preferences. It behooves us to look carefully at how this sort of widget is usually implemented in the industry rather than simply (re)inventing visual conventions ourselves.
Collapse
11: Re: Curriculum Phase 1 (response to 1)
Posted by Ola Hansson on 02/28/03 06:13 PM
This first iteration (Curriculum Phase 1) will be a stand-alone package that can act as a light-weight alternative to the future (SCORM-integrated) Simple Sequencing package (Curriculum Phase 2). In this version, all the navigation and other metadata belonging to the course (say) will have to be entered manually by the curriculum designer.

The future will most certainly bring the cool stuff Michael mentions, though.

But until then neither sequencing, branching, nor content packaging are vital concerns. What is vital at this point, though, is that we get a comprehensible and comprehensive UI.

BTW, we've updated our mockup s page and will continue to do so in response to your feedback.

Collapse
13: Re: Curriculum Phase 1 (response to 1)
Posted by Don Baccus on 02/28/03 07:06 PM
Michael ... XML is how stuff will be imported into the system, without doubt (since every specifies that this is how it will be done)

But internally as Dave and Ola point out, the best thing to do is to use our standard db_multirow and similar tools to extract the data.  I mean ... we'd have to do that anyway, and if we converted it to XML ... where does the designer work with that?  They write code to munge it to something that's fed to the user's browser?  Page designers can't do that.  They can, however, use templating tags that are just extensions to the HTML they're used to, which is what they get with the current scheme.

As far as using frames ... the place for a site customizer to do that is in the site's master template.  You would build your frame structure (top/bottom, left/right, whatever) there and include the proper horizontal or vertical curriculum bar in your top or left frame and the <slave> (i.e. template output for the package page being generated) in the other.

Forcing frames at the low-level requires all sites using the feature to be frame-based.  But not forcing them at the low-level does not *preclude* building sites using the feature from using frames.

That's the difference.  Put the choice in the hands of the site designer.  This isn't about being "anti-frame" but rather being "anti-locking-you-into-frames"

We might want to provide sample master templates that implement top/bottom, left/right styles both with and without frames for folks to reference as examples, of course.

Collapse
15: Re: Curriculum Phase 1 (response to 1)
Posted by Michael Feldstein on 02/28/03 07:36 PM
As I said before, I'm hardly an expert in implementation. I just wanted to point out that (a) as you're deciding the best way to implement this, you'll want to think about use cases involving SCORM, and (b) if you're going to offer multiple templates as examples the designers can use for ideas, it might be good to have one example that uses <div> in a way that many course designers will be familiar with.
Collapse
16: Re: Curriculum Phase 1 (response to 1)
Posted by Ola Hansson on 02/28/03 07:38 PM
Michael,

Do you have any links to pages that demo or describe visual conventions of progress indicators?

Thanks.

Collapse
14: Re: Curriculum Phase 1 (response to 12)
Posted by Carl Robert Blesius on 02/28/03 07:43 PM
At this point I do not really care about the backend, but I do care about the frontend. Let's forget about frames (sounds like it would unnecessarily complicate things) and focus on content that is ON OTHER servers. What about a popup window with a genuine progress bar and a simple list of milestones (with links to extended information)?

Nice point about visual conventions Michael. Do you have anything that we could look at to get some ideas? Here are some UNFILTERED results WITH PICTURES from a quick search (could not find anything specific to education):

http://www-106.ibm.com/developerworks/usability/library/us-progind/

http://www.mit.edu/~jtidwell/language/progress_indicator.html

http://www.codeproject.com/cs/miscctrl/progressdialog.asp

http://www.sun.com/smrc/web/components/g5_progress_indicator.html

http://msdn.microsoft.com/msdnmag/issues/03/01/CQA/default.aspx

http://www.15seconds.com/issue/020109.htm

Collapse
17: Re: Curriculum Phase 1 (response to 1)
Posted by Michael Feldstein on 02/28/03 10:01 PM
I'm traveling now but will dig out some examples of e-learning progress indicators when I'm back home next week.
Collapse
18: Re: Curriculum Phase 1 (response to 1)
Posted by Don Baccus on 02/28/03 10:39 PM
Surely we want the progress indicator to be a template that site designers can diddle with to their heart's content? (with a reasonable default, of course)

Some people might want right-to-left or bottom-up, never can tell! :)

Collapse
19: Re: Curriculum Phase 1 (response to 1)
Posted by Ola Hansson on 03/18/03 01:50 PM
Here's a couple of questions that we'd like to find answers to before we commence development of the datamodel for Curriculum (which will be the first step and start pretty soon, we hope).

The presupposition is that Curriculum will show up in OpenACS 4.7 / dotLRN 1.1 ...

  1. Should the development work be conducted on the head of the trunk or on the tip of the oacs-4-6 branch?
  2. Should we demand that people use PG 7.3 and thereby be able to take advantage of the increased default parameter limit of 32 params (compared to 16 in 7.2) and the new maximum attribute length of 64 characters (compared to 32 in 7.2)?
  3. Do we want to base this package on the Content Repository or on plain acs objects, i.e., content_type vs object_type? We're planning on having two custom types, "curriculum" and "element", and though we are not storing the actual learning content in this package nor in the CR (rather, Curriculum points to content anywhere) we might benefit from CR features such as search, etc, for element and curriculum descriptions for example ... OTOH acs objects may very well suffice in this case.
  4. What privileges/roles do we need? The basic "read", "admin", etc., or something more granular like "curriculum-create", etc?
  5. We should probably prepend the Curriculum types and table names with a short prefix since names such as "curriculum_curriculums" tend to become rather long. How about "cu_"?
  6. Anything else technical concerning the datamodel that I'm forgetting?
I'm sure that more questions will arise soon, especially when it comes to Oracle.

Oh, what comes to mind right about now is; what is the preferred way to split up (Oracle) package create scripts? Should package definitions go in one script and the package bodies go in another?

/Ola