跳到主要內容

我的孩子不想努力,我怎麼從旁給力


先前發現老家有個被棄置的蛇板,覺得可惜就拿回來玩。但我覺得很難玩,連站都站不上去。但小女兒卻是興致盎然,很開心的一直試著滑,也邀請要好的鄰居女孩一起玩。我也覺得蛇板應該非常符合她的興趣。但是一兩週後的某天,突然發現她不玩了,我感覺應該不是玩膩了,因爲才剛拿到沒多久。而且不管是鄰居女孩或我找她一起玩,她就是不願意,問她原因也不說,只說就是不想玩了。

以我對她的了解,她應該會很喜歡蛇板,而且她剛開始看到蛇板明明很興奮,為何後來突然就不想玩了呢?我覺得小女兒很擅長戶外運動,我也希望能多多培養她這個專長,所以她不玩蛇板我覺得很可惜。但我也不可能威脅說:「去給我溜蛇板,不然我就要丟掉它」。因此我選擇接受她這個狀態,也不一直追問她原因。

我先嘗試以身作則的方法,就是每次跟小女兒在門口玩時,我就會花點時間練蛇板,也會上網看一些基本教學,慢慢從能先站上板子滑一小段,到漸漸可以滑行較長距離,後來更熟了之後也學會轉彎及加速。過程大概花了一兩週,小女兒也都在一旁看著我滑。我心裡希望小女兒因著看著我學習、進步的過程,能夠激起她想要學的慾望。在我溜得蠻順了之後,我就試探性的鼓勵她說:「你看很簡單喔!多練習幾次就可以了」、「你看這不難喔,我本來也是不會,現在也會滑了」。你覺得這樣她就願意玩蛇板了嗎?沒有!

就這樣又過了一陣子,我跟老婆討論到這件事時,她就提醒我,小女兒幼稚園時期,也是一時興起堅決要學直排輪,沒想在第二堂課摔了個大跤之後,就再也不學,好說歹說都沒用,每次上課都只是把直排輪鞋帶去,坐在場邊看其他孩子溜,再也沒上過場。從這個事件我突然意識到,小女兒可能是怕摔。於是我就嘗試性的問小女兒:「爸爸幫你買護具好不好?」,她很開心地答應了。穿上護具後,果然她就願意再次開始玩蛇板,甚至會假摔來試試護具的防護力。過沒多久,就很順利地學會滑蛇板,而且熟練之後,就因為嫌熱把整身護具脫掉。後來蛇板就變成她的戶外遊戲之一,不用我叫也會自己去玩。

從這件事我得到幾個經驗:

🍀 要接納孩子的放棄與失敗。當小女兒突然不玩蛇板時,我沒有一直鞭策她或逼問她原因,就先接納她放棄的決定。沒有因為這個放棄就對她施加更多壓力,或是對她失望。

🍀 父母不能總是從自身經驗來幫助孩子。我以為展示我自己的成功學習蛇板經驗可以誘發小女兒的學習慾望,那是從我自己是愛好學習的人的角度出發的,這種方法對我這類人有用,但對小女兒沒用。這是個只從自己經驗出發的失敗激勵法。

🍀 了解孩子非常重要。如果不是知道小女兒小時候的直排輪摔跤事件,我恐怕也會無法找到對的方式來幫助她,因為孩子常常無法或不願意清楚表達自己的困難,這時父母如果夠了解孩子,就能針對孩子的特性來引導他們。

🍀  教養需要夫妻同心協力。老婆長期陪伴孩子參加各種活動,對女兒的個性與各種事件暸若指掌,我經常與老婆討論孩子狀況,才能得知那件摔跤事件。因此綜合我與老婆的能力,最終才成功地引導女兒學會溜蛇板。

留言

這個網誌中的熱門文章

innerHTML 的安全風險

問題 若你要實作一個使用者輸入的功能,並把輸入的內容顯示在網頁上時,應避免把使用者輸入的值直接指定給某個 element 的 innerHTML 。因為若是使用者輸入包含 HTML、JavaScript, innerHTML 就會解析並執行: var userInput = '<img src="javascript:alert("XSS")">' element . innerHTML = userInput ; 因此可能 user A 的惡意輸入,會被系統顯示到 user B 的畫面上,進而執行特定成程式碼而造成 XSS 攻擊 。 解法 一般會先想到 encode HTML,但是如果只是要顯示文字,將使用者輸入值指定給 textContent 會更簡單,無需 encode,該值會被當成純文字處理,並不會執行 javascript。 var userInput = '<img src="javascript:alert("XSS")">' element . textContent = userInput ;

XMind使用心得

使用FreeMind有好一段時間,不過畫面單調一直是我不滿意之處。 XMind在畫面上好看很多,節點形狀樣式、分支線樣式有多樣選擇,也可以匯入FreeMind的檔案。 類似Excel般,工作頁活頁的概念也很不錯,可以將多個相關的心智圖存在一起。 可以某個分支為中心來檢視的功能也很令人激賞,完全符合心智圖那種可見樹、可見林的特性。 不過使用上有幾項缺點: 1.不能設定節點的預設文字大小。 預設應該是10點字,太小了,但是「喜好設定」內沒有地方可以修改,需要每次自己加大字型,很麻煩。 2.沒有加大字型的動作可以設定快速鍵。 我喜歡不只是用顏色,還有用字型的大小來凸顯主幹、分支的差別,不能快速的增大、縮小字型很不便。

ZK 教學 - 使用 MVC 或 MVVM?

不管是現在剛開始接觸 ZK 或是用過一陣子的人都可能會遇到的問題是到底要用 MVC 或 MVVM 的方式開發。從 ZK 8 之後又把 MVVM 的能力更佳的擴展,所以 MVVM 會是一個功能更強的開發方式。但 MVC 在使用上比較直覺,仍有其優勢,所以我想決定性的因素會比較是 開發者的偏好 及 專案的特性 。你可參考下面的比較來決定哪種方式比較適合你。 優勢比較 MVVM ViewModel 較不易受畫面變動影響。 因為 ViewModel 沒有變數直接指向 ZK 元件,因此若是畫面上有元件更改,ViewModel 一般不需要修改 ViewModel 較易於在不同頁面中重用。 因為 ViewModel 只包含資料跟業務邏輯,若是不同頁面需要的資料跟業務邏輯相同,就可以重用同一個 ViewModel 例如 A 頁面按按鈕執行搜尋,B 頁面點選單執行同樣的搜尋,則可以重用同一個 ViewModel 中的 command,只是兩個頁面 data binding 寫在不同的元件上。 畫面較易於重用(易於模組化)。 透過 shadow component 跟 template 機制,可以將一段頁面的片段做成可以接受傳入參數 套用 Responsive Design 的成本較低。 通常需要針對不同裝置設計不同版面,但是顯示的資料內容大同小異,因此 ViewModel 多半可以重用 易於套用美工所設計的畫面,或是網路上現成的元件。 易於整合第三方 javascript library 或 widget。 因為 ZK 8 提供了一個可以讓你透過 javascript 去呼叫 ViewModel 中的 command (client side binding) 的方式來跟後端溝通 ViewModel 的可測試性較好。 因為 ViewModel 不需要繼承特定類別跟實作特定介面,可以輕易地執行單元測試 MVC 操控元件方式直覺好學、易懂。 MVVM 控制元件較不直接,需要了解 zk framework data binding 的行為 可以完全使用元件所提供的所有 API。 仍有極少部分 ZK 元件行為沒辦法用 MVVM 控制。例如產生 Messagebox , Listbox.renderAll() , Popup.o...