[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Self-platform-dev] HTML Export discussion...
From: |
Dinesh Joshi |
Subject: |
[Self-platform-dev] HTML Export discussion... |
Date: |
Fri, 2 May 2008 13:45:50 +0530 |
Hello everybody,
As you all are aware that we're working on HTML export of courses.
This feature has been refined ( its not yet up on beta. It will be
shortly. ) but there are some issues that need to be addressed:
1. HTML code is heterogenous
2. Inconsistent formatting
Lets take 1 first, What I observed was there are mainly two sources of
data ( courses ).
a. The platform's editor
b. Imported courses
I dont think there is a third source of data. Both sources are feeding
unstructured information into the platform. Well not really
unstructured but its not structured for semantics but for formatting.
Now lets take a scenario where a course is imported and then later
modified. We have no idea what kind of HTML will be generated then.
Why? Well simply because TinyMCE ( the WYSIWYG editor on the platform
) formats the text without including CSS i.e. it puts all kinds of
HTML formatting tags which is bad while the original page may refer to
one or more CSS ( External / Embedded ). Due to this we have
heterogenous HTML code.
Also, sometimes the imported courses have javascript which they rely
on for some amount of formatting. Now I completely understand
javascript is great for fancy effects but when it comes to imparting
knowledge it simply creates more issues than it solves.
>From what I've explained I guess you must've inferred that issue 2 is
in-part an effect of issue 1.
My conclusion is, whether its html, scorm or docbook export it doesn't
matter. These issues are going to remain until a robust solution is
implemented.
After giving it some thought I think its best that we encourage the
users to write courses in a structured language which is formatting
free. An example would be the editors used by media wiki. Or in my
opinion a javascript editor which can generate docbook tags would be
even better.
This will solve the two problems that I mentioned earlier and will
ease up the amount of processing that needs to be done while exporting
courses. You must've noticed that even huge courses are getting
exported in a flash. It can be even faster if it weren't for scrubbing
some of the unnecessary HTML tags from the courses. And we've not even
implemented a caching mechanism! ( And we don't feel the need to do so
).
What are your thoughts?
--
Regards,
Dinesh A. Joshi
- [Self-platform-dev] HTML Export discussion...,
Dinesh Joshi <=