 |
|
 |
||
|
||||
 |
ספר מודפס חייב להיות סטטי מפני שזו מגבלה של טכנולוגית ההפצה שלו. מדוע לגרור את המגבלה הזו למדיום שעיקר יתרונו לא באיכות התצוגה הסטטית, אלא באינטראקטיביות וקישוריות? הדפדפן המודרני נראה לי פלטפורמה ניטראלית ואינטראקטיבית טבעית. אין כמובן צורך לחייב אף אחד ליצר גירסה מורחבת ואינטראקטיבית של ספר לימוד. משרד החינוך צריך לקבוע שכל פלטפומרמה שישתמשו בה לצרכי חינוך בבתי ספר בישראל תתמוך בקבוצה ידועה של תקני אינטרנט פתוחים מקובלים. המשרד צריך להודיע על נכונותו לסבסד באמצעות תלושים שיועברו לבתי ספר או מורים רכישת גירסאות ממוחשבות של ספרי לימוד בתנאי שיתאימו לתקנים שנקבעו. צריך לאפשר ליצרנים להתחרות מול הלקוחות שיהיו בתי הספר, או מורים. התחרות תעשה את שלה ותקבע את אופי המוצר. במקום ששימוש במנוע משחק כזה או אחר (ויש כאלה גם ב-html5), יגרום למוצר להיות אפקטיבי יותר ללקוחות, תווצר גירסה אינטראקטיבית. במקום שהפיכת חווית הלימוד לעבודת צוות תהיה מועדפת ע"י הלקוחות, זה מה שהם יקבלו. ומי שיקנה צילום של ספר סטטי - יבושם לו. משרד החינוך צריך לקבוע רק את התקנים של שדה המשחק, ולאתחל את השוק באמצעות תלושים. אני מציע לא להתערב גם בטכנולוגיות החומרה ו-Form factor. |
 |
 |
 |
|
|
|
||
|
||||
|
האם אינטראקטיביות וקישוריות מספקים איכות למידה משופרת ביחס לספר סטטי? מצד אחד זה מובן מאליו, מצד שני זה מובן מאליו שזה ממש לא כך, כמו שקריאה של ספר פרוזה סטטי היא חוויה ששום אינטראקטיביות של משחקי מחשב לא דומה לה. כמובן, לפתח לומדות זה גם כן אחלה, אבל הדיון כרגע הוא לא על לומדות אלא מה עושים עם ספרי הלימוד הקיימים, והאם ממשיכים במצב שבו הם מודפסים על נייר או שעוברים לגרסה אלקטרונית (שתרוץ על מכשיר שאולי גם יריץ לומדות). |
|
|
|
|
|
|
||
|
||||
|
מה שהצעתי אינו שולל פרוזה או ספר סטטי אחר. המו"ל פשוט מחליט לא להשתמש בסקריפט. זה עניינו. ירצו יקנו, לא ירצו זבש"ו. העניין הוא שתווצר תחרות. אם ללומדה יש יתרון בתחום מסויים, באותו תחום הספרים יהפכו מהר מאוד ללומדות, מפני שאחרת לא ירכשו אותם. חשוב שיהיה רצף. כלומר שהמעבר מספר ממוחשב ללומדה לא יחייב שום רגולציה, או החלטה מרכזית של משרד החינוך. אני מאמין שהמעבר יתרחש כתוצאה מלחץ השוק. אם לעומת זו יחליטו שמשתמשים ב pdf, אז העסק פשוט ישאר תקוע שם. |
|
|
|
|
|
|
||
|
||||
|
דווקא epub הוא לא רע ודי קרוב ל-HTML עובר הצגת תוכן. לעומת זאת אם אתה רוצה משהו יותר אינטראקטיבי אתה צריך כבר (לרוב הדברים) גם תוכנה בצד השרת או איזושהי תוכנה מקומית. כאן כבר אין כמעט סטנדרטים. אלא אם כן אתה רוצה שיעבדו מול תוכנת שרת שבשליטת מו"ל הספר? | |
|
|
|
|
|
||
|
||||
|
עד כמה קוראי ePub-ים מתעתדים לתמוך בהטמל5? כבר עכשיו הם תומכים בתמונות, כמובן. האם הם גם יממשו JS בשלב כלשהו? | |
|
|
|
|
|
||
|
||||
|
אני לא מסכים שחייבים תוכנה בצד השרת או אפילו שרת בכלל, אם כי בהחלט רצוי לצרכי מעקב, היזון חוזר ועידכון. בכל אופן אפשר לעשות הרבה מאוד אינטראקציה תוך שימוש בדפים סטטים ותכנות רק בצד הלקוח. (רוב משחקי ה-flash וה-html5 עובדים כך). בקשר לתכנות צד שרת אני לא יודע וצריך לחשוב. אולי אפשר לאפשר באמת תכנות צד שרת לא בתכני הלימוד עצמם אלא רק לצורך מעקב של היצרנים ובשרתים של היצרנים. כלומר התכנים הלימודיים עצמם סטטיים בשרת של ביה"ס, ותקן לסוגי המעקב המותר ליצרנים ואיך צריכים להיות הקישורים להם. אבל אין לי הצעה מדוייקת לכך. | |
|
|
|
|
|
||
|
||||
|
אמרת שאתה רוצה סטנדרטיזציה. רק הפניתי את תשומת ליבך ש-HTML5 לא בדיוק מספק את זה. לדוגמה: איך מחפשים במסמך? באופן כללי נראה לי שהקריטריון המעשי לסטנרדטיזציה הוא עד כמה קל להחליף יצרן אחד ביצרן אחר. כלומר: כל עוד אתה לא תלוי בתוכנות מיוחדות שאצלו על השרת, נראה שזה בסדר. | |
|
|
| חזרה לעמוד הראשי | המאמר המלא |
| מערכת האייל הקורא אינה אחראית לתוכן תגובות שנכתבו בידי קוראים | |
 RSS מאמרים |
כתבו למערכת |
אודות האתר |
טרם התעדכנת |
ארכיון |
חיפוש |
עזרה |
תנאי שימוש
|
© כל הזכויות שמורות |