利用 Material-UI 統一 UI framework —— 均一前端工程師宜陞技術分享

Why we do this: 統一「自由奔放」的 UI 框架

1 個網站套用 5 個 UI 框架

開發前端 APP 的前置作業,不外乎是根據設計師送來的設計圖,從 UI 框架中選擇適用的元件(component)。

但均一團隊從「選擇 UI 框架」這件事開始,就是道複雜的多選題。

在還是好傻好天真的 ES5 時代,均一的網頁大多是套用 Bootstrap,當我們開始 migrate 到 ES6 + React,由於適用於 React 的 UI 框架仍未發展成熟,為了有充足的元件庫可以使用,均一先後引入了 Material-UI(註一)及 React-Bootstrap。

除了前面提到的歷史因素,造成均一 UI 框架混亂的關鍵因素還有維護套件註定要面對的「套件升級」。

當工程師發現現有的 UI 框架無法提供所需的元件,通常會考慮以下幾種解法:

  1. 自己刻出需要的元件
  2. 升級套件,擴充現有套件的元件庫
  3. 引入一個符合需求的新套件

如果是功能陽春的元件,通常會選擇「自己的元件自己刻」,但如果元件的功能複雜又遇上專案死線在即,往往會考慮引入新套件以加速開發,至於「套件升級」則因為牽一髮動全身的特性,總是淪為最不得已的選擇。

隨著新的 UI 框架持續被引入,舊框架的維護被長時間擱置,當我們鐵了心要規範框架的使用時,早已在均一的 codebase 中引入 5 大包 UI 框架 —— 引入了 Bootstrap、Semantic-UI、Material-UI、React-Bootstrap、Ant-Design。

其中較常被使用的 Material-UI、React-Bootstrap 都還停留在最初被引入時的版本號 version 0.x.x。

而過去過於「自由奔放」的管理原則,也產生了以下的技術債:

  • coding style 混亂
  • UI 框架版本老舊
  • 同一個頁面套用兩種以上框架,導致 UI 凌亂

為了償還前面提到的種種技術債,我們開始訂定相關的還債計畫。

註一:Material-UI 是當前流行的 UI 框架之一,它用來提供網頁中的元件(如:Button、Input)。

How we do this 1: 對 UI 框架專一

限縮框架數量

要確保 UI 框架不再多元發展,最直接的方式就是限縮框架的數量,因此目標之一就是選定「一個」適合長期使用的框架,並持續維護、更新。

當選定的框架無法提供工程師所需的元件,仍可以選擇引入較輕量的套件加速開發,確保工程團隊能靈活的運用第三方套件——但是,禁止再引入一整包框架!

選擇 Material-UI

在選擇框架前,我們調查了當前熱門的 UI 框架,考量到 Material-UI 的元件庫及 styling 解決方案相對完備,瀏覽器支援度符合團隊需求,且均一也已經有不少頁面是以 Material-UI 進行開發。

因此,統一改成 Material-UI 的成本較小、易用性高,最後雀屏中選,成為均一主要的 UI 框架。

筆者在前一段提到均一使用的 Material-UI 還有個陳年的老問題:版本過舊,當我們開始研究 Material-UI 的發展近況時,才赫然發現 Material-UI 早已從 material-ui 轉移到 @material-ui/core

因此在採用 Material-UI 的第一個階段性任務就是:升級 Material-UI (from material-ui @0.19.0 to @material-ui/core @4.9.1),並在升級過程中改善 styling 相關技術。

How we do this 2: 選擇合適的 style API

升級 Material-UI 的過程,除了更新元件的語法,也花了不少心力思考怎麼善用 Material-UI 豐富的 styling 解決方案。最先遇到的問題就是如何取捨 style API(註二)。

使用 Material-UI 的 styled-components API 取代 styled-components library(註三)

在考慮引進 Material-UI 的 style API 之前,均一團隊慣用的解決方案是 styled-components library (以下簡稱 styled-components)。

使用舊版 Material-UI 時,因為 styled-components 的 CSS 權重不足,無法蓋過 Material-UI 元件的 inline style,所以我們仍是以 inline style 來實作 Material-UI 的元件客製化。

新版的 Material-UI,styled-components CSS 權重不足的問題已被解決,除此之外,Material-UI 也受到 styled-components 的啟發,進一步提供了 styled-components API (以下簡稱 styled API)。

由於 styled API 幾乎可以取代 styled-components,經過以下考量,均一團隊決定使用 styled API 取代 styled-components:

  • CSS 權重:使用 styled API 不需要額外設定 CSS 的權重
  • Theming:使用 styled API 可以直接取得 Material-UI 的 theme object,不需要混用 styled-components 的 theming 系統(註四)
  • Coding style:後面會提到我們也開放使用另一種 Material-UI 的 style API ——hook API。由於 styled API、hook API 的 CSS 皆是以 JSS 撰寫 (styled-components 的 CSS 則是用 String templates),選擇 styled API 能讓 CSS 的 coding style 更統一。

註二:style API 是 Material-UI 提供的 styling 解決方案之一,style API 可用來撰寫元件的 CSS。Material-UI 主要提供了 3 種 style API:hook API、styled components API、higher-order component API。 

註三:styled-components library 是一個 JavaScript 套件,它用來撰寫元件的 CSS。Material-UI 受到 styled-components library 啟發而發展出 styled-components API。 

註四:theme 可以用來更換網站的主題設計,如 styled-components library 與 Material-UI 皆提供所屬的 theme 系統(<ThemeProvider>)。可透過調整 theme 的設定,統一更換網站的主題(如:顏色、形狀、陰影)。

使用 classes API 客製化內層元件,並捨棄 global class

當遇上 Material-UI 元件含有內層元件時 (如:<Button> 其實內含了 MuiButton-rootMuiButtom-label 兩層元件),Material-UI 針對內層元件的客製化提供了兩種方法:classes API 和 global class。

考量到 styled API 可以直接鎖定 global class,不像使用 classes API 還需要自訂義 classes,我們一開始選擇使用 global class 來客製化內層元件:

// 鎖定 global class .MuiButton-label 來客製化 Button 的內層元件 label
const StyledButton = styled(Button)(
    ({ theme }) => ({
        backgroundColor: 'white',
        '& .MuiButton-label': { // 鎖定 global class
            padding: [[theme.spacing(3)]],
        },
    }),
);

天真地用了一陣子後,才發現鎖定 global class 其實有個潛在問題:global class 是會變動的。

當同一個元件樹中有巢狀的 theme 時,內層 theme 的 global class 會被加上 index,如:MuiTypography-root 會變為 MuiTypography-root-67

假如 styled API 鎖定了 MuiTypography-root ,可能會因為巢狀 theme 產生的 index 導致 CSS 選擇器失效。

而此問題的解法就是:classes API。由於 classes API 會產生獨立的 class ,不會因為巢狀 theme 導致失效,為了避免潛在問題,我們便捨棄了 global class,並統一使用 classes API:

// classes API:
const useButtonStyles = makeStyles(theme => ({
    root: {
        margin: 3,
    },
    myLabel: {
        padding: [[theme.spacing(3)]],
    },
}), { name: 'useButtonStyles' });

const StyledButton = ({ ...props }) => {
    const classes = useButtonStyles();
    return (<Button
        classes={{
            root: classes.root,
            label: classes.myLabel, // 改用 classes API 來客製化 Button 的內層元件 label
        }}
        {...props}
    />);
};

使用 hook API「拆分 style sheet」與「客製化多層的子元件」

隨著決定以 classes API 來實作內層元件客製化,團隊內也開始嘗試使用另一種 style API:hook API (makeStyles) 來操作 classes API。嘗試的過程中發現在某些情境下 hook API 能更有彈性的操作 style sheet。

例如在拆分 style sheet 的情境中,hook API 可以輕易的拆分 style sheet 並注入不同的元件:

const usePopupBtnStyles = makeStyles(theme => ({
    root: {  // 拆分出 root
        height: 70,
    },
    deleteContained: { // 拆分出 deleteContained
        color: theme.palette.primary.contrastText,
    },
}), { name: 'usePopupBtn' });

const PopupBtnDelete = ({ ...props }) => {
    const classes = usePopupBtnStyles();
    return (<Button
        classes={{
            root: classes.root, // 注入 root
            contained: classes.deleteContained, // 注入 deleteContained
        }}
        {...props}
    />);
};

const PopupBtnCancel = ({ ...props }) => {
    const classes = usePopupBtnStyles();
    return <Button classes={{ root: classes.root }} {...props} />; // 只注入 root
};

在另一種情境,當元件內有多層的子元件時,hook API 也能產生多份 style sheet 分別注入各個子元件:

// hook API
const useStepStyles = makeStyles(theme => ({ // 產生 4 份 style sheet
    labelContainer: {
        textAlign: 'center',
    },
    label: {
        fontSize: '24px',
    },
    stepLabelRoot: {
        background: theme.palette.primary.main,
    },
    stepRoot: {
        flex: 3,
    },
}), { name: 'StyledStepLabel' });

const StyledStepLabel = ({}) => {
    const classes = useStepStyles();
    return (<Step
        classes={{ root: classes.stepRoot }} // 其中 1 份,注入 Step 的 style
    >
        <StepLabel
            classes={{ // 其中 3 份,注入 StepLabel 的 styles
                root: classes.stepLabelRoot,
                labelContainer: classes.labelContainer,
                label: classes.label,
            }}
        >
            stepLabel
        </StepLabel>
    </Step>);
};

在 Material-UI 提供的 3 種 style API 之中,均一團隊主要仍使用 styled API,同時也持續嘗試 hook API 該如何和 styled API 配搭運用。

How we do this 3: 善用 theming,style 共用最大化

移除 styled-components 的 ThemeProvider

過去我們一直沒有明確規範 theming 的用法及用途,在各個專案中也會混用 Material-UI 及 styled-components 的 ThemeProvider

延續前面提到的,均一團隊將逐步淘汰 styled-components,所以在正式啟用 theming 前做的第一件事就是移除 styled-components 的 ThemeProvider 並統一使用 Material-UI 的 ThemeProvider

善用 Material-UI 的 ThemeProvider

在統整各 package 的 theming 時,我們嘗試用以下原則進行重構:

  • 適用均一全站的 theme 統一放在 commonMuiTheme
  • 適用各個 package 的 theme 會寫在各自的 customTheme
  • 不適合套用整個 package 的元件客製化,則使用 style API
  • 同一個元件樹建議只有一個 ThemeProvider,避免巢狀 theme

重構的第一步,我們便根據設計師開出來的元件規範,寫出適用全站的 commonMuiTheme

// commonMuiTheme.js
const commonMuiTheme = {
    palette: {
        text: {
            primary: 'rgba(0, 0, 0, 0.6)',
        },
    },
};

第二步,則是在各 package 的 entry point 撰寫 customTheme,並透過 Material-UI 提供的 createMuiTheme 來 merge commonMuiThemecustomTheme

// entry point: index.js
const customTheme = {
    palette: {
        primary: courseMenuPalette.primary,
    },
};

/* 
 * createMuiTheme 能讓 customTheme 覆寫
 * commonMuiTheme 中相同的 key
 */
const muiTheme = createMuiTheme(commonMuiTheme, customTheme);

const show = () => (
		<ThemeProvider theme={muiTheme}>
        <Grouping/>
		</ThemeProvider>
);

最後,如果元件的客製化不適合放在 commonMuiThemecustomTheme,則會使用 hook 和 styled API 來實作。

How we fix problems: multiple ThemeProvider cause class name conflict

除了 migration to Material-UI,均一團隊極力想完成的另一件大事就是 migration to React。

為了同時兼顧專案開發與均一團隊的技術提升,我們會在開發項目中安排 React migration,常見的作法是將頁面中的局部功能替換成 React,以逐步達成整個頁面的 migration 。

這個作法的結果,以均一的課程主題頁為例,課程主題頁只有「content」及「切換出版社 Button」是以 React + Material-UI 實作,在整個頁面中,「content」及「切換出版社 Button」是兩棵不同的元件樹,即兩棵樹有各自的 ThemeProvider

這種單一頁面多個 ThemeProvider 的情形,極有可能會發生 class name conflict,均一團隊在升級 Material-UI 的過程中就遇上了各種類型的 conflict。

以下範例可重現同一頁面中有兩個平行的 ThemeProvider 會產生的問題。範例中的 Theme1 照理來說要為紅色,但因為 class name conflict 導致顯示為綠色:

const Theme1 = createMuiTheme({
  palette: {
    primary: {
      main: red[400]
    }
  }
});
const Theme2 = createMuiTheme({
  palette: {
    primary: {
      main: green[600]
    }
  }
});
const ThemeConflict = ({}) => (
    <div>
      <ThemeProvider theme={Theme1}>
          <Icon color="primary">add_circle</Icon> {// 預期為「紅色」,實際看到為「綠色」}
      </ThemeProvider>
      <ThemeProvider theme={Theme2}>
          <Icon color="primary">add_circle</Icon> {// 預期為「綠色」,實際看到為「綠色」}
      </ThemeProvider>
    </div>
);

造成 conflict 的原因是,兩個平行的 ThemeProvider 各自產生了同名的 global class MuiIcon-colorPrimary —— 不像巢狀 theme 還會為內層 theme 的 class 加上 index,由於 Theme2MuiIcon-colorPrimary 較晚被引入,導致 Theme2 的 class (綠色) 覆蓋掉 Theme1 的 class (紅色)。

<!-- output HTML -->
<div>
		<span class="material-icons MuiIcon-root MuiIcon-colorPrimary" aria-hidden="true">add_circle</span>
		<span class="material-icons MuiIcon-root MuiIcon-colorPrimary" aria-hidden="true">add_circle</span>
</div>
// output CSS
.MuiIcon-colorPrimary {
    color: #ef5350; // red[400]
}

.MuiIcon-colorPrimary {
    color: #43a047; // green[600]
}

當同一頁面中的 ThemeProvider 數量越來越多時就越有可能發生 conflict,甚至隨著環境 (local or production)不同還會遇到不同類型的 conflict。

幸好 Material-UI 都有提供自訂「class 生成規則」的方法,我們也在踩雷試錯的過程中找到了各種 conflict 的解法 —— conflict 都可以透過 Material-UI 提供的 createGenerateClassName 及 style API 的 name 解決。

What’s next?

工程團隊費時兩個月終於完成了 Material-UI 升級,儘管仍有許多未竟之事(如:將其他 UI 框架替換成 Material-UI),但對均一的前端開發環境來說已是一大福音,光是可使用的元件大幅增加,就為開發帶來極大的便利。

為了確保統一 UI 框架之路能繼續走下去,工程團隊仍持續努力在 migration to React 或進行重構時,從其他框架轉移到 Material-UI。

同時,我們也正在規劃和設計團隊協作進行 Atomic Design(註五),並基於 Material-UI 規劃共用的元件庫。

如果對均一前端的未來發展感興趣,可以持續關注我們,一起體會均一前端技術的成長與突破。

註五:Atomic Design 是一種設計方法論,此方法論將元件區分為五個層級 (由小到大為:原子、分子、組織、模板、頁面) 以促進元件的一致性與可擴展性。


均一招募中!

如果你對前端軟體開發充滿熱忱,而且跟宜陞一樣期待用科技來影響教育,我們正在尋找軟體工程師,馬上到招募頁面查看職位詳情!


作者|江宜陞(均一平台教育基金會前端工程師)
編輯|陳又慈(均一平台教育基金會實習生)

分享這篇文章:

相關文章

生命的改變從教室開始

在孩子長大成人之前,有將近一半的時間在學校度過,許多孩子的成長與改變也在這裡發生。有些孩子從討厭數學到數學成績名列前茅、有些孩子從討厭學習到願意學習,卻也有些孩子無法前進,不論是學習動機低落、教育資源受限,都是可能的原因之一。

也因為看見了這些孩子的困境,我們希望透過科技的力量,提供孩子們優質且免費的學習資源,落實教育平權,打造一座沒有牆的教室。

我發現,原來教學就該是看見孩子真正需要被幫忙的地方,而不是看教學指引而已。

大同國小.林政琦老師

教室裡的改變

均一在一次次與學校、課輔班的合作中,看到許多成長與改變的故事。

我們看到有孩子從一開始放棄數學、不敢發問,到後來能主動舉手發問,甚至能教其他同學;也看到有老師體悟到成績不是一切,重要的是孩子們的學習態度以及如何面對挑戰與困難。

可能有一些東西並不是,成績單上面看得到的,有的時候我們好像,太在乎這個學生的表現是集中在成績這一塊。

文英國中.李延慶老師

孩子有無限多的可能正在教室中發生,邀請你與我們一起,創造更多免費優質的教育資源,讓更多孩子的未來有好的改變。

你也能一起參與改變

均一是一個非營利組織,為了專注於我們的願景使命,我們不承接政府預算、不發展有對價關係的盈利,仰賴與我們有相同願景使命的大眾捐款支持,期待集合眾人之力,實現真實的共創與共好。

邀請你一起參與 >> 公益支持

不分城鄉,教室裡的學習弱勢

不論在都市或是偏鄉,教室裡都存在著學習弱勢。每個孩子的學習步調、吸收知識速度都不同,如果孩子們沒辦法在教室裡學到適合自己步調與發展需求的內容,都有可能處於學習弱勢。我們希望透過平台上免費有趣的學習影片與習題、科技化的平台輔助功能,讓這些孩子能夠按照自己的步調學習,培養自信找回成就感,發揮原生天賦。

我們藉由課輔班合作計畫與學習扶助計畫,讓更多學習速度不同的孩子,得到差異化的教學,弭平學習落差,並在過程中持續鼓勵、陪伴孩子與教師

課輔班合作計畫

透過與課輔班合作,均一提供平板筆電載具、專業師資培訓與觀課陪伴,協助課輔班老師能以遊戲化的數學學習模式,讓弱勢孩子重拾學習興趣、鞏固基本學力。合作期間,也看到許多老師陪伴孩子的動人故事,我們記錄這些過程與故事,也邀請有興趣的你,點擊下列文章更了解計畫成果,也認識課輔班老師的故事!

有位平常學習上較落後的孩子,跟我分享,是磨數營讓她愛上數學。甚至跟我說 : 努力沒有做不到的事!

屏東躍愛課輔班 林綺漩 老師

學習扶助計畫

在 106 學年度,均一與苗栗縣和屏東縣分別合作進行「結合均一的課中補救」試辦計畫。藉由一般課堂的時間,抽離需要額外學習扶助的孩子到「學習扶助班級」,搭配均一平台的使用,有效診斷學生的學習斷點,提供個人化學習。

經過三年的顯著成效與現場教師的正面迴響,109 學年度起,均一在苗栗、屏東推動學習扶助「深化」模式,除了繼續數學課中學習扶助外,期盼藉由更深度投入的專案教師、更具規模的教師社群、更系統性的增能與支持,為學習扶助的師生帶來更有效的教與學。

學習扶助計畫進行的這幾年,我們不只看見許多孩子學習的進步,更看見許多老師教書育人的理念,邀請你點進下方文章,認識其中一位專案教師的故事。

苗栗文英國中李老師照片

帶孩子走出教室裡的無力感 —— 苗栗延慶老師分享

在眾多均一平台上的老師當中,今天想特別與大家分享延慶老師的故事。延慶老師是「均一課中學習扶助深化專案」的老師,他觀察到,傳統一體適用的教學當中,班級內存在的學習落差影響了孩子的學習信心;透過「課中學習扶助」,老師們能用不同的教學方式,幫助孩子建立學習成就感,以及對未來的信心。

了解更多 »

你也能一起參與改變

均一是一個非營利組織,為了專注於我們的願景使命,我們不承接政府預算、不發展有對價關係的盈利,仰賴與我們有相同願景使命的大眾捐款支持,期待集合眾人之力,實現真實的共創與共好。

邀請你一起參與 >> 公益支持

是老師,也是教育創新家

在均一有一群老師,不只出現在第一線教學現場,分享如何利用平台提供孩子們差異化教學,給學校或課輔班的老師,更設計出多元跨領域的課程,激發孩子們的學習動機。

我們在台灣擴大推廣 Code.org 的 Hour of Code 一小時玩程式,團隊夥伴製作中文化插電與不插電的程式課程、結合創意的教學設計,讓 Code.org 這套全球廣受好評的程式課程,在台灣的使用濃度達到世界排名第九、亞洲排名第二,讓臺灣的程式教育能夠與國際接軌。課程資源與師資培育,都逐步與國際接軌。

「模組化的課程設計,不論對教師教學、學生學習都有很大的幫助;因為課程規劃得很完整,老師能很清楚第一步要如何開始、接下來又該怎麼做,以及背後的教學目標,搭配程式闖關遊戲,小朋友會更有動機去嘗試、思考,甚至他們做完後、還會想再做一次,主動地去複習所學!」

太平國小 陳宜均老師

為了讓孩子透過程式學習運算思維,均一也設計了一系列 Scratch 課程,採取專案導向學習 (Project-Based Learning),以深入淺出的講義或影片引導,經由不同領域主題,’當孩子面對給予的任務,將學習如何解構問題、摘要重點、發現規律,循序漸進地練習程式的思考。

數電快閃教室

數電快閃教室計畫,是團隊夥伴到教學現場透過「數學 X 電腦科學」的跨領域課程,將好玩、互動性高的電腦科學融入數學的課程內容,讓孩子覺得原來數學可以這麼有趣,學到的知識也可以加以應用。均一也透過此課程和現場老師分享跨領域教學,探索更多的學習可能

後續雖遇上五月份的疫情,團隊發揮創意推出「線上快閃教室」,以線上的形式,快閃 18 所國小的線上教室,帶來「自學力就是你的超能力」主題分享,總計有 329 位學生參與,我們希望藉由這個活動,讓孩子在疫情期間能夠找到自己學習的目標和節奏。

當我們 Code 在一起說故事

「當我們 Code 在一起說故事」專案計畫,也就是平台上「電腦科學起步走|一起說故事」課程,是源自 Google 開發的 CS First,均一除了將其中文化翻譯,並且配合 108 課綱將課程內容和教學模組在地化。課程內容以程式作為跨域學習的槓桿,融合電腦科學、語文、音樂、藝術,鼓勵孩子用想像力編寫動人的故事,並且練習程式的思考。

此課程也獲選「 第三屆未來教育.臺灣100 – 全臺年度百大創新教學專案」的獎項殊榮。

每個孩子都希望能創造屬於自己的故事,細緻的課程架構,並附有專人引導的自學影片,孩子可以根據自己的學習和創作速度前進,人人都有成就感!

KIST: 拯民國小.宋亭緻老師

你也能一起參與改變

均一是一個非營利組織,為了專注於我們的願景使命,我們不承接政府預算、不發展有對價關係的盈利,仰賴與我們有相同願景使命的大眾捐款支持,期待集合眾人之力,實現真實的共創與共好。

 邀請你一起參與 >> 公益支持

教室裡的風景

每個人的生命當中,都有那麼幾位令人印象深刻的老師。有的老師幽默風趣、有的嚴厲而堅毅,有的老師像是再生父母,讓我們從學習與探索中,發揮生命更大的價值。

在 2021 年 的停課期間,有一種老師大量增加了,他們是守護孩子學習不中斷的「抗疫老師」,在短短幾天內,設法與孩子取得聯繫、使用各種數位工具,並給予遠距支持。

事實上,在在台灣的每一個角落,一直都能看見這些義無反顧為孩子付出的身影。以下是均一在推動教育改變的路上,遇到的幾位老師,希望透過簡短的文字、影片,與你一起分享,均一在教育現場的看見。

均一教師的身影

安溪國中——靜怡老師

靜怡老師任教於新北市安溪國中數學科,七年前開始使用均一教育平台,並將均一應用在「適性分組班」與自己的班級教學當中。

「讓孩子不會只是之前的挫折一直累積到最後,讓他可以在這裡找到讓他產生信心的地方。」/ 靜怡老師

點我看靜怡老師的完整分享 >>

 

安溪國中靜怡老師

 

高雄岡山教會課輔班——子婕老師  

子婕老師雖罹患罕病,仍完成中央大學數學、資工雙主修,更因為從小便與媽媽在教會服務弱勢孩童。研究所時對數位教學產生興趣、畢業後即投入弱勢教育。2020 年導入均一教學後,子婕老師與課輔團隊投入其中,幾乎天天討論到深夜。雖然孩子的學習成就並沒有一飛沖天,但她認為,孩子的正面心態、學習品格才是第一順位。

「我希望這些孩子記得,小時候有這麼一群人拼 死拼活努力去愛他們,他們是值得被愛的。」/ 子婕老師

點我認識「弱勢課輔班計畫」>>

均一如何支持教師

均一經由支持教師,更規模化地影響孩子。

在子婕老師參與的弱勢課輔班計畫中,均一在兩年內培訓了 110 位教師,其中有 87% 的老師過去未曾使用數位平台輔助教學,在經過師資培訓後,提升了 20% 老師的教學信心,大多數老師更能夠獨立於課堂中教學,陪伴孩子探索數位學習平台,找到適合的學習內容。

除了弱勢課輔班計畫之外,均一長期與苗栗、屏東學習扶助班級合作,培養學習扶助科技教師。疫情期間,更曾累積上千名老師同時在線參與研習培訓,支持全台教師、家長陪伴孩子停課不停學。疫情之後,超過半數的現場教師仍持續採取科技搭配教學,數位學習將是教師、學生、家長不可或缺的關鍵能力。我們期待持續投入培訓資源與教學法開發,支持現場教師,進而支持更多孩子。

你也能一起參與改變

均一是一個非營利組織,為了專注於我們的願景使命,我們不承接政府預算、不發展有對價關係的盈利,仰賴與我們有相同願景使命的大眾捐款支持,期待集合眾人之力,實現真實的共創與共好。

邀請你一起參與 >> 公益支持