Forum .LRN Q&A: Curriculum Phase 1
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.
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)
And Polyxena's website's pretty classy ... I like the flag favicon, too.
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.
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).
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.
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!
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.
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.
Do you have any links to pages that demo or describe visual conventions of progress indicators?
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):
Some people might want right-to-left or bottom-up, never can tell! :)
The presupposition is that Curriculum will show up in OpenACS 4.7 / dotLRN 1.1 ...
- Should the development work be conducted on the head of the trunk or on the tip of the oacs-4-6 branch?
- 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)?
- 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.
- What privileges/roles do we need? The basic "read", "admin", etc., or something more granular like "curriculum-create", etc?
- 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_"?
- Anything else technical concerning the datamodel that I'm forgetting?
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?