[Using Sakai] Twenty-First Century Interactions on Sakai?
Marshall Feldman
marsh at uri.edu
Wed Oct 17 09:28:39 PDT 2012
Dear Amber,
Thank you very much. This is quite helpful.
Personally, I use Eclipse with the Aptana plug-in to author web sites.
But I do not think Dreamweaver or SoftChalk would do any better in
addressing the set of issues that remain. I may not understand Sakai
sufficiently well to see how it overcomes these issues, but here is a
discussion of the most important issues I see.
Initially I thought Lesson Builder would allow me to remedy most of the
shortcomings I find with Sakai. Chief among these was the need to keep
left-side tabs visible for students to access various tools, even though
links to the tools were available elsewhere and presented in a much
better context (for example, as in your ePortfolio). This shortcoming is
particularly troublesome because a course using many tools needs a
plethora of left tabs, and Sakai provides no means to organize them into
groups, interactively guide navigation, or even to distinguish their
appearance. So students quickly become lost in a site using many tools.
Further, LB's portability and reproduction between instances of a course
would reduce the tedium of creating new sites and reduce errors. Third,
I thought LB would allow course sites to have a look-and-feel associated
with their subject matter. This is one of the great advantages of
web-based teaching, but Sakai militates against such customization. (I
have been told that in the early stages of developing Sakai's
philosophy, administrators overrode the programmers' suggestion of
making Sakai highly customizable. Instead, the administrators wanted a
standardized, one-size-fits-all look and feel. I think Malvina Reynolds
wrote a song about this <https://www.youtube.com/watch?v=2_2lGkEU4Xs>.)
But Lesson Builder is not consistent in the way it treats side tabs. I
have found that students do not have to see the Resources tab to access
resources, but they cannot access assignments unless the Assignments tab
is visible. Even worse, documentation for LB is on par with the rest of
Sakai, which is to say the documentation is superficial and aimed at the
most technically unsophisticated faculty members. Consequently, I've not
found even a list of what tools need visible tabs to be usable versus
what tabs can be safely hidden. IMHO, all tabs should be optional.
LB also only partly solves the portability issue. Ostensibly, links on a
LB page will be updated properly relative to the current course in all
course replications. But because LB does not easily take advantage of
contemporary web technologies (e.g., HTML5, CSS3, JavaScript, script
libraries like jQuery, etc.) */and/* because Sakai's built-in editors
and web-authoring tools are extremely inferior to web-development
applications like Dreamweaver or Aptana, one must develop sets of web
pages outside Sakai and then import them into Sakai to store them on the
Sakai server. (I've used the alternative of storing the pages on a
regular web server and just using links in pages on Sakai.) This poses
all kinds of problems. The production and development file hierarchies
must match on Sakai and the development site; otherwise, the developer
must go through the tedious task of editing links to replace page
locations on the development system with links on Sakai. This is not
always easily possible. To make matters worse, Sakai uses cockamamie,
internally generated file names, so the course designer (instructor) has
no easy way to make the two systems correspond.
WebDAV is also notoriously buggy, especially on PC systems
<https://en.wikipedia.org/wiki/WebDAV#Microsoft_Windows>, and not all
web-development tools can use WebDAV. But Sakai does not support FTP.
If one nonetheless uses regular web pages instead of LB, then the whole
issue of portability comes up. If the web pages are hosted in a course
site, then the web designer must manually update every link in the
custom web pages. I had to write a jQuery plug-in that uses a hash table
to look up links. Thus, a web page can have a reference like <a
href="$MAIL">, and the plug-in will replace $MAIL with the URL of the
current Sakai site's mail (Messages) tool. The course designer just had
to update the hash table for each course instance. But it needn't be so
hard.
There's also the issue of reusing tools in multiple course instances.
For instance, if the instructor discovers a bug in a particular script
that's being used for several courses, then each course must be fixed
separately and manually because jQuery security prevents students from
accessing shared files. Sakai does provide some ways around this, but
they seem to boil down to a choice between either all files being public
or having a separate instance for each course site. This is also why
using relative paths makes things easier but does not completely solve
the problem.
IMHO, Sakai should include a set of widgets much like those provided by
jQuery UI <http://jqueryui.com/> (accordion navigation tools,
insert-able calendars, etc.). Moreover, the widgets should be easy to
use and not require any web-design experience. (The year I got my
engineering master's degree at Cornell, my department split with one
part becoming Computer Science. Then I worked for MIT as a systems
programmer. So I'm more comfortable with this technical stuff than most
faculty members are.) Some specialized web design and development
expertise may occasionally be necessary, but this should be the rare
exception. (I teach an urban studies course on urbanization, and the
next time I teach it online I hope to use a subway map
<https://www.readwriteweb.com/hack/2011/12/create-subway-maps-with-jquery.php>
as the site's main navigation page. I don't expect Sakai to support such
things.) The kinds of technologies one sees on TiddlyDesktop
<http://digitaldimsum.co.uk/tiddlywiki/> are available now and should be
easily usable in a LMS like Sakai to allow course designers to use web
technology to full pedagogical advantage.
Sorry to be so long-winded. My university started using Sakai in 2009,
and for most of the time since I've designed my own web pages as you
suggest. But for the reasons outlined above and as you note, this is
very difficult and time-consuming. I intended my original post to raise
the issue that currently Sakai is so twentieth century and does not at
all take full advantage of technologies that are common today. Thanks
to your reply, this note elaborates on some of the challenges of using
HTML pages within Sakai.
Thanks again for your suggestions. I look forward to trying them.
Marsh Feldman
On 10/17/12 10:30 AM, Amber D. Marcu wrote:
> Hi Marshall,
>
> My response is long overdue and may not be all that useful at this
> point, but perhaps for future semesters it may help. I'm
> piggy-backing on what Mr. Algaze suggested regarding the use of
> Resources and web pages.
>
> I really like Lesson Builder, too. But as an instructor with some web
> design knowledge, I've done a lot of work in Sakai CLE using HTML
> pages stored in Resources to present learning modules of information.
> A "lite demonstration" of some pages that load into the main frame of
> CLE can be seen in my ePortfolio here
> <https://scholar.vt.edu/access/content/user/adevans/Public/DVDPortfolio/Samples/samples/training/track_d/Introduction/homepage.html>.
>
>
> If you have comfort in creating and using web pages, you can either
> choose to create files directly within the CLE or by using a 3rd Party
> software (such as /Dreamweaver/ or another easy-favorite of faculty,
> /SoftChalk <http://softchalk.com/>/) and using WebDAV to upload the
> files. I've used both, but I prefer to use Dreamweaver and to upload
> the files. SoftChalk is great to create Flash-based quizzes,
> animations, etc. though! They even have a cloud offering, now. But I
> like doing it with DW, because I like the control and I can use
> relative urls for linking the pages together, saving me trouble in the
> long run when I copy courses from semester-to-semester.
>
> I'm not going to say it's an easy process to do it this way, but it's
> not impossible and often results in the outcomes I desire. However,
> there are caveats: you need to know something about web design (for
> Dreamweaver), you should know something about creating learning
> modules of content (for SoftChalk or equivalent), and you should be
> willing to spend a lot of time doing both of these as the initial
> creation can be quite time-consuming. That said, subsequent changes
> and adjustments are far less painful and you always have an "original"
> copy sitting on your computer (or in the cloud if you wish) for
> whenever you wish to reuse the content.
>
> One more thing to note. If you want to use JavaScript, oftentimes
> this can be accomplished by checking an option within the Resources
> area that houses said script. At least in rSmart Sakai CLE 2.8 under
> Resources > "Folder_Name" > Actions > Edit Details > "User-uploaded
> HTML may contain dangerous scripts. To override default behavior and
> allow unrestricted HTML, check this box." This little thing has
> allowed for me to run php RSS feeds, (most) .js files, and other items
> I probably should not be able to enjoy.
>
> If you're interested in looking into using Resources to house web
> pages (or the pages from something like SoftChalk
> <http://softchalk.com/>), I've included some handouts from when I was
> working at Virginia Tech to help explain what I'm talking about.
>
> Best of luck,
>
> Amber D. Marcu
> Academic Technology Consultant, rSmart
> amarcu at rsmart.com <mailto:amarcu at rsmart.com> | (530) 426-2372
>
>
> On Fri, Aug 24, 2012 at 5:30 PM, Algaze, Louis Contractor, eDataTech
> <ljalgaze at nps.edu <mailto:ljalgaze at nps.edu>> wrote:
>
> Marshall,
>
> Have you explored using web pages within the Resources area and
> putting a
> Web Content link in the left navigation to specified page(s)?
> Although
> the Rich Text Editor strips out all <head> content you can embed
> javascript calls into the <body> of a page by using a standard
> script call:
>
> <script type="text/javascript" id="templateScript"src="full or
> relative
> path to .js file"></script>
>
> Once that is there you should be able to go crazy with using that
> javascript.
>
> If you do not plan to modify any of the pages with the rich text
> editor
> you can use your favorite html editor and upload pages or an
> entire site
> using the WebDav (Upload/download multiple items) feature.
>
> All of this should be able to be performed Out of the Box, with no
> special
> configuration to the best of my knowledge.
>
> Louis
>
>
> On 8/24/12 12:02 PM, "Marshall Feldman" <marsh at uri.edu
> <mailto:marsh at uri.edu>> wrote:
>
> >Thanks to Sam, Matt, and David who quickly answered my query.
> >Unfortunately, I am "just" a faculty member and, like most faculty
> >members, do not have access to the config package and all that. If I
> >were to suggest changing the overall University-wide
> configuration, the
> >administration would probably appoint a committee, which would
> recommend
> >hiring a consultant, which would require a budget augmentation, which
> >would take about 4 years to tell me they can't support the change.
> >(Sorry, this cynicism is well-earned.)
> >
> >One of my colleagues showed me a way around this that should work. So
> >I'm going to give it a try first.
> >
> > Marsh Feldman
> >
> >
> >On 8/24/12 1:21 PM, Sam Ottenhoff wrote:
> >>> ... On a
> >>> regular web page using a jQuery plugin this is almost trivial. You
> >>>just have
> >>> a short amount of text and then a "read more" link that
> expands the
> >>>text
> >>> when the student wants to read the whole thing. See this
> example. But
> >>>how to
> >>> do this in Sakai?
> >> Modify the Sakai config package and change the goodTags property to
> >> allow all input from users. It's a five minute change that
> will stop
> >> all HTML filtering and sanitation in Sakai.
> >>
> >> Making this change would be a security disaster if you do not have
> >> full trust in every *possible* user of your system. If you
> allow users
> >> to input Javascript into a web-based system, you are open to a
> >> gigantic class of attacks
> >> (http://en.wikipedia.org/wiki/Cross-site_scripting).
> >>
> >> If you don't have full trust in every single user in your
> system, then
> >> you need to add functionality centrally to your portal rendering
> >> instead of doing it as an instructor in a browser. Add new styles
> >> into the rich-text editor configs. Then render those new
> styles using
> >> the centralized jQuery code in your primary Sakai JS files.
> >>
> >> --Sam
> >
> >_______________________________________________
> >sakai-user mailing list
> >sakai-user at collab.sakaiproject.org
> <mailto:sakai-user at collab.sakaiproject.org>
> >http://collab.sakaiproject.org/mailman/listinfo/sakai-user
> >
> >TO UNSUBSCRIBE: send email to
> >sakai-user-unsubscribe at collab.sakaiproject.org
> <mailto:sakai-user-unsubscribe at collab.sakaiproject.org> with a
> subject of
> >"unsubscribe"
>
> _______________________________________________
> sakai-user mailing list
> sakai-user at collab.sakaiproject.org
> <mailto:sakai-user at collab.sakaiproject.org>
> http://collab.sakaiproject.org/mailman/listinfo/sakai-user
>
> TO UNSUBSCRIBE: send email to
> sakai-user-unsubscribe at collab.sakaiproject.org
> <mailto:sakai-user-unsubscribe at collab.sakaiproject.org> with a
> subject of "unsubscribe"
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-user/attachments/20121017/bc863e81/attachment-0001.html
More information about the sakai-user
mailing list