Re: [ 作業06] jQuery動態換頁效果

週六, 四月 29. 2017

(1)作業網址:http://mepopedia.com/~css105-2b/hw06/hw06-1045445017

(2)製作心得:第一次使用動態的換頁效果,讓網頁在設計感上更加分,而
這次找的圖都有自己在去加文字、陰影等,看起來比較完整好看,也學到
了新知識,滿好的。

Re: [作業05] jQuery動態網頁初探 -fadein

週五, 四月 28. 2017

(1)作業網址: http://mepopedia.com/~css105-2b/midterm/midterm-1045445044
(2)製作心得: 又是一個新技法好酷
學號 1045445044

Re: [ 作業06] jQuery動態換頁效果

週五, 四月 28. 2017

(1)作業網址:http://mepopedia.com/~css105-2c/hw06/hw06-1045445117

(2)製作心得:動態換頁效果簡潔卻不失情調,也增加網頁瀏覽的樂趣,
原本想增加文字描述,但喜歡圖內有字的排版,後將圖片排上文字,文
字描述除了簡介外,也讓圖片增添豐富性,使兩者互相呼應。

Re: [期中作業] HTML與CSS應用--網站實作

週五, 四月 28. 2017

(1)作業網址:http://mepopedia.com/~css105-2a/midterm/midterm-1045445082/index.html
(2)網站主題: season甜點
(3)導覽列選項/分類項目(對應檔名):
推薦美食(index) 菜單(Untitled-1) 線上選購(Untitled-2) 分店(Untitled-3) 外部連結(Untitled-4)
(2)設計對象: 18~40女性
(3)色彩計畫:粉紫色系
(4)風格設定、預期成效: 簡單的色塊做搭配
(5)製作心得:
製作過程中加入了flexslider,研究了很久,依然無法將圖片置中。但很有成就感,希望下次能做更好~

從一個故事說起,談談企業應用架構的演變史

週五, 四月 28. 2017

企業應用架構是指一整套軟體系統的構建,通過合理的劃分和設計組合在一起,支援企業方方面面的經營運作。

不論是傳統企業,還是互聯網公司,發展到一定階段,都需要一整套體系化的應用架構來支撐其運轉。良好的、合理的應用架構可以支援企業高效開展業務,控制經營風險,而混亂的、不合理的應用架構則會限制企業的快速發展,成為企業增長與變革的瓶頸。

企業信息化建設已經發展了幾十年,傳統企業和成熟互聯網企業的應用架構並沒有本質的區別。本文將通過一個線下小型門店成長為多元化集團的發展歷程,逐步向讀者展示企業應用架構的演變和設計的理念。

完整的企業架構(EA,Enterprise Architecture)分析構建,包括業務架構、應用架構、技術架構、數據架構,本文聚焦[b]應用架構[/b],更加關注軟體系統設計與公司經營管理的關係。

不論是 C 端產品經理或者 B 端產品經理,理解應用架構的建設思路,能夠幫助你更輕鬆的理解公司的業務運轉,以及各個系統存在的目的與你所負責工作在整體團隊中的定位和價值。

[b]傳統企業的應用架構演變[/b]

[b]小門店的 Excel 管理之路[/b]

我們將從一個最簡單的案例入手,來展開故事。

假設你是一名個體經營者,在小區中開了一家小門店,售賣居民常用的生活用品。門店不大,只有十幾平米,平常由你一個人負責經營管理,包括採購、擺貨、銷售。

為了更準確、科學的打理你的生意,你設計了一個 Excel 文件來管理你的商品與銷售數據。

實際上你只需要做三張表格:

● 第一張表格存儲了你的貨品信息
● 第二張表格存儲了你的採購記錄
● 第三張表格存儲了你的銷售記錄

這三張表格的結構和關係如下圖所示:
[img]http://www.finereport.com/tw/wp-content/themes/BusinessNews/images/2017043002.png[/img]

上圖採用了 ER 模型來描述三張表的邏輯結構,* 和 1 的含義是表和表之間的關聯關係,例如採購記錄和商品信息是多對一關係,即採購記錄表中的每條數據只能對應商品信息表中的一條數據,商品信息表中的一條數據可以對應採購記錄表中的多條數據。

因為你採用了科學的數據表格管理,記錄了門店的所有採購入庫和銷售數據,這讓你的經營變得井井有條;通過這些原始數據,你可以準確的管理庫存、計算利潤、掌握暢銷品和滯銷品,還能通過數據透視表製作銷售日報和月報。

實際上你通過以上三張表格管理自己的生意,已經是一個管理軟體的雛形了。所有的軟體系統無非都是對數據的增刪改查操作;可以說,如果使用得當,Excel 也可以做出一套小型的軟體系統。

[b]小超市的輕量級ERP之路[/b]

因為你善於使用信息技術來協助你做生意,你的買賣發展迅速;很快,你將小門店升級成為一家小型超市,並且僱傭了幾個店員來幫你。作為店長,你興奮的繪製出自己的第一張組織架構圖,夢想著事業會繼續壯大。
[img]http://www.finereport.com/tw/wp-content/themes/BusinessNews/images/2017043003.png[/img]

因為經營的貨品更加豐富,日交易量成倍增長,並且有好幾名員工需要做數據錄入分析工作,這時 Excel 已經難以滿足經營管理的需要。因此明智的你在開店之前,就決定採購一套 ERP 軟體來協助你管理超市。

因為你還處於創業期,資金有限,通過仔細挑選,你選擇了一套輕量級的 ERP,並且只購買了其中的幾個核心模塊,這樣既可以控制成本,又可以讓你經營的軟體設備升級。

現在,我們可以繪製公司的第一張應用架構圖,公司擁有一套系統,包含三個模塊。
[img]http://www.finereport.com/tw/wp-content/themes/BusinessNews/images/2017043004.png[/img]

[b]通過CRM拉近與客戶的距離[/b]

為了更加準確的理解、認識你的客戶,同時也為了能夠拉近你和客戶的距離,你打算通過 CRM 軟體進行更加科學的客戶管理。

你設計了一套會員積分制度,所有的客戶都能免費辦理會員,這樣你就可以記錄下關鍵的客戶信息,而且你的小夥伴建議你開通一個微信公眾號,讓客戶能夠通過微信來查詢自己的積分。

這個主意太棒了!你追加購買了幾個 ERP 的模塊,雖然 ERP 中也包含了 CRM 模塊,但是研究後你認為內置的CRM模塊功能有限,不支援對接微信,行銷功能也不夠強大,因此你新購買了一套 CRM 軟體,和 ERP 進行了一定程度的對接,同時申請了微信公眾號,找外包公司做了一些定製化開發。這樣上述想法就都實現了!

我們繪製出公司的第二張應用架構圖。
[img]http://www.finereport.com/tw/wp-content/themes/BusinessNews/images/2017043005.png[/img]

可以看到,核心的客戶信息資產模塊都在 CRM 中實現,其中內置了行銷模塊、消息推送服務 Msg 模塊,包括 SMS 、EDM(Email Direct Marketing)和微信消息推送。

● CRM 主要聚焦客戶資料的管理和行銷服務,主要用戶為店長和運營人員;
● ERP 主要聚焦於超市的進銷存以及財務業務,主要用戶為營業員、出納、採購、庫管和會計。
[b]請注意:這裡已經產生了應用架構設計的概念。[/b]

公共號、ERP 和 CRM 每個系統都為了解決某一大類的業務問題而存在,有各自清晰地定位、分工和目標用戶,每個系統相對獨立又互有關聯,內置若干模塊,每個模塊都是為了解決某一大類業務問題下的某一小類問題而設計。

在這張圖中我們使用了分層描述,靠近 C 端用戶的微信公眾號在最上層,支援業務運轉的 ERP 放在中間層,偏底層的客戶信息集成 CRM 放在最下層,這樣可以清晰地看出幾個系統的層次關係,同時也在一定程度反映了系統和業務之間的邏輯對應關係。

[b]中型連鎖超市的架構之路[/b]

業務進展很順利,你已經開了五家中型連鎖超市了,員工數量達到了幾百人。公司走上了正軌,標準化的管理分工已經成型,不同職能單元各司其職。

為了有效管理團隊,並且讓內部流程更加順暢,你邀請專業的 IT 諮詢公司幫你重新梳理了公司的業務目標、組織架構、運營流程,通過引入 OA、HRM 以及重構 ERP 等手段,對不合理的制度,低效的流程進行了改造。

公司成立了信息技術部,其中項目部配合諮詢公司以及軟體外包公司進行系統改造或實施新系統,運維部負責保證伺服器、網路的穩定。
[img]http://www.finereport.com/tw/wp-content/themes/BusinessNews/images/2017043006.png[/img]

你理解數據對公司發展的重要性,所有的管理決策都應該基於對數據的分析和判斷,因此你邀請諮詢公司幫你強化公司的數據分析能力。

諮詢顧問建議你實施數據倉庫(Data Warehouse)和 BI(Business Intelligence)項目,原因有幾點:

● ERP 系統和 CRM 系統都有[url=http://www.finereport.com/tw/]報表製作[/url]模塊,但兩個系統的數據相互孤立,不利於整合分析。
● 業務系統的底層數據結構並不適合做複雜的[url=http://www.finereport.com/tw/]數據分析[/url],常見的多維分析更需要一套數據倉庫常用的星形數據結構和雪花型數據結構。
● 成熟的 [url=http://www.finereport.com/tw/]BI 系統[/url]可以讓你的報表分析與多維數據探查更輕鬆,其中的儀錶盤更能夠讓你輕鬆掌控公司全局的核心指標變化。
● 企業經營中很常見的一個問題,就是經營分析指標統計口徑太多,造成管理混亂和溝通障礙,除了在管理上規範公司級指標的定義,也需要一套底層數據架構,消除上游各個異構系統的孤島和屏障,統一管理匯總數據和指標計算。
諮詢顧問建議,雖然目前公司的業務系統還沒有到非常複雜的階段,但數據倉庫可以幫助企業更快速高效準確的理解、捕獲、使用數據,做好基礎建設工作,培養員工的數據分析意識和方法,通過數據來進行決策。隨著業務的拓展和系統複雜性的提升,數據倉庫的存在價值將越來越明顯。
[img]http://www.finereport.com/tw/wp-content/themes/BusinessNews/images/2017043007.png[/img]

在數據倉庫項目中,同時構建了數據集市(Data Mart)。數據集市介於 BI 展現層和 DW 數據底層之間,是數據倉庫的數據子集。數據倉庫的服務對象通常為全公司或全集團,但是不同部門可能有自己的數據分析訴求與指標管理訴求,這時候通過統一的數據底層,封裝出針對某個部門使用的小型數據集市,可以保證數據流的合理性、可追溯性,同時研發部門可以完全復用 DW 和 BI 的技術能力,輕鬆地設計實施 DM 。

如果希望數據倉庫在企業中真正發揮作用,不僅僅是軟體系統實施問題,更重要的是公司層面的經營分析思路體系化,指標管理規範化,以及數據部門組織架構、與業務部門合作流程設計問題,同時還需要提升全員數據化管理運營的概念和意識。軟體本身並不能解決企業的問題,只有配套的架構、流程、制度與意識,才能發揮軟體的功效。

[b]應用架構跟隨業務而變[/b]

由於公司經營良好,很多商品可以從供應商處拿到很好的價格,經過供應商授權,公司決定開展 2B 業務,成立了大客戶銷售部,公司將作為供應商的 B 端渠道,挖掘企業客戶。

為了讓銷售工作高效展開,對銷售人員進行嚴格的過程管理,同時也為了保留客戶資料,避免銷售獨佔客戶資源,根據 CTO 建議,公司決定實施操作型 OCRM(Operating CRM)項目。同時由於各部門經常出現個性化的軟體開發訴求,軟體外包維護的成本高,效率低,公司決定招聘研發團隊,用自己的隊伍進行軟體的二次開發。
[img]http://www.finereport.com/tw/wp-content/themes/BusinessNews/images/2017043008.png[/img]

在設計 OCRM 系統時。CTO 面臨兩個選擇:

[b]方案一[/b]:新做一套獨立於現有 CRM 的 OCRM

[b]優點[/b]:

OCRM 系統已有成熟的軟體可以選擇,無需從頭開發;兩個系統邊界清晰,分工明確,便於未來各自的發展與演變。

[b]缺點[/b]:

應用架構會略有複雜,需要將原有的 CRM 和 OCRM 做數據打通,對原有的客戶模型做升級。

[b]方案二[/b]:在原有的CRM基礎上開發新模塊

[b]優點[/b]:新開發的模塊完全基於公司業務流程和模式設計,適配程度高。

[b]缺點[/b]:新開發模塊成本高速度慢,系統邊界模糊,導致以後維護升級時模塊管理的混亂。

綜合評估兩套方案實現的成本和速度,考慮到對未來業務變化的靈活支援,同時為了避免影響核心 CRM 業務的穩定性,CTO 決定採用方案一,讓兩個系統各自聚焦,互相獨立,邊界清晰,雖然無形中增加了公司應用架構的複雜性,但可以快速實施支援當前的緊迫業務,並靈活應對未來公司的銷售業務變化。
[img]http://www.finereport.com/tw/wp-content/themes/BusinessNews/images/2017043009.png[/img]

[b]一般來講[/b]:

B 端客戶的數據模型和 C 端客戶差異非常大,B 端客戶模型關注組織架構和人員角色的描述,C 端客戶模型關注客戶本身個人信息的描述,即便應用系統中將客戶模型和操作型系統分開建設,客戶模型一定會做成兩套以支援不同的上下游業務系統。

上圖為了簡化表述,只繪製了一個模塊「客戶信息」,但讀者應該認識到:該模塊應該包含 B 端、C 端兩套客戶模型。實際上有的公司會明確將兩套客戶模型在應用架構中分開設計並且分別建設,以便更加準確的體現應用架構中的業務概念。

廣義上來講,CRM 代表一種企業對待核心客戶資源的管理理念和運營方法,CRM 是一種概念而非某一個獨立的應用系統。

大型的企業涉及多條業務線,不同的業務線有不同的客戶群。企業需要有統一的客戶視圖和管理理念,以及強大的 IT 系統支援,來實現準確的客戶接觸點管理,充分挖掘客戶群體實現精準銷售,積極有效的維護企業和客戶的關係。

CRM 體系化的系統建設中包含了客戶建模、會員積分管理、行銷中心、銷售線索和過程管理、小型數據倉庫或數據集市、統一客戶視圖、客戶畫像和數據挖掘、電話銷售中心等等。

不同的企業對系統的劃分和團隊的管理各不相同,但所有 CTO 都應該明白 CRM 是一套應用體系,而不僅僅是某個單一的獨立應用系統。

至此,我們已經繪製出一套一般企業的簡化版應用架構圖,以及一張常見的組織架構圖。可以看到,應用系統的建設,是根據業務的發展變化逐步完成的,每個系統都有獨立存在的意義和價值。

[b]多元化業務帶來的應用架構演變[/b]

[b]在線商城業務帶來了互聯網化管理[/b]

公司的零售業務發展進入了瓶頸期,CEO 需要尋找新的增長點。

經過評估,決定開展電商業務,新成立了電商部,從市場上聘來了某電商平台 VP 作為部門負責人,直接給 CEO 彙報。

為了學習互聯網公司,以技術力量推動業務創新,電商部組織結構參考了一般互聯網公司組結構,有自己獨立的研發團隊,設置了產品崗位,產品技術總監給電商部負責人彙報。

電商部受到 CEO 極度重視,給與極高自治權和最高資源支援,同時 CEO 還將之前線下的客服團隊升級為公司一級部門,直接給 CEO 彙報,統一處理線上線下的客服與售後業務。
[img]http://www.finereport.com/tw/wp-content/themes/BusinessNews/images/2017043010.png[/img]

新業務開展,大家幹勁十足,因為電商部產品技術總監和公司 CTO 之間不存在彙報關係,產品技術總監為了快速推進項目,所有決策基本只是告知 CTO 。

產品技術總監作為純互聯網背景專家,認為購買現成軟體套件不利於系統的二次開發和自主維護,長遠來看會限制公司業務發展,希望整套系統實現自主研發。

雖然 CTO 極力反對,但經過電商部負責人和產品技術總監的遊說,CEO 聽取了總監的建議,並且總監承諾自己的研發團隊效率極高,一定會在承諾之日交付系統。

產品技術總監設計的應用架構體系,包括 PC 和行動版的前端應用,以及完整的後端系統,包括訂單、售後、客戶信息、會員、行銷、賬號、CMS 。此外,倉儲、財務系統會接入現有ERP的服務,配送模塊直接與第三方配送服務商系統對接。

對於這個架構設計,CTO 比較不滿,認為客戶信息和賬號管理不應該重複建設,而應該統一規劃管理,但產品技術總監一心快速推進實施,對於信息技術部開發效率低的情況他早有耳聞,他可不希望被一些不可控力影響導致自己的項目延期,因此 CTO 的抗議他不予理會。

升級後的客服部門,新建了 20 人坐席的電銷中心,以支援主要來自於線上的電話客服訴求。新成立的客服團隊需要 CallCenter 系統開展業務,雖然 CallCenter 的主要服務群體是線上業務的客服話務員,但 CEO 為了在一定程度上安撫 CTO 的不滿情緒,將 CallCenter 項目安排給 CTO 負責。

CTO 採購了一套成熟 CallCenter 來支援 400 熱線業務,對此安排電商部的產品技術總監沒有什麼異議,但在 CallCenter 的實施中卻出現了問題。

因為 CallCenter 系統只負責電話作業,其中的客戶資料一般由上游系統提供。但是公司現有兩套客戶資料,一套是保存在 CRM 的線下業務客戶資料庫,一套是在線商城的客戶資料庫。

為此只能在 CallCenter 中新增一套客戶庫,將另外兩套客戶庫數據同步過來,這樣客服人員才能在 CallCenter 中查到公司級別的完整客戶信息。
[img]http://www.finereport.com/tw/wp-content/themes/BusinessNews/images/2017043011.png[/img]

[b]信息孤島與主數據管理[/b]

電商系統如期上線,業務發展迅速,電商團隊的運營和產品人員年輕,聰明,充滿活力,思維活躍,玩法眾多,電商技術團隊響應迅速,產品經理和技術團隊的無縫配合,讓技術力量真正推動了業務的增長。

公司賺錢了,老闆很開心。但很多問題也同時暴露了出來。我們先來看看之前的應用架構。
[img]http://www.finereport.com/tw/wp-content/themes/BusinessNews/images/2017043012.png[/img]

之前為了快速上線,有一些應用架構遺留問題沒有解決。現在公司有三套客戶資料庫,線下客戶通過微信公共號訪問 CRM 系統中的客戶信息,在線商城的客戶通過線上商城訪問 e-Store 系統的客戶信息。當客戶致電 400 時,電銷業務員(TSR)訪問的是從 e-Store 和 CRM 同步過來的客戶信息。

線上客戶關注公共號後,查不到自己的資料,這讓客戶感覺很詭異。

線下客戶想在線上商城下單,發現之前登記的賬號不能使用,需要重新註冊完善資料,客戶很煩躁。

數據同步 30 分鐘一次,有時候客戶剛修改完資料再致電 400,客服查到的客戶信息不是最新的,讓客戶很生氣,客服很苦惱。

有的客戶喜歡打電話讓客服改資料,因為客戶資料是單向同步,客服無法協助客戶修改資料,客戶很氣憤,為什麼你們連這點服務都做不好!

很多客戶在線上線下都消費,但由於在數據倉庫中冗餘出了兩個客戶對象,不論是線上團隊還是線下團隊,都無法做更準確的客戶畫像和跨渠道消費行為分析。

CEO 很生氣,找到 CTO 和電商產品技術總監,質問怎麼回事。

CTO 回答,我們遇到了嚴重的信息孤島問題!

由於 CRM 和商城後台數據互相孤立,導致核心客戶資源不同步,不統一,讓公司無法得到一個完整準確的客戶視圖。如果要解決這個問題,必須對應用架構進行改造,並且改造比較耗時。

CEO 很鬱悶,沒想到應用架構不合理會影響到業務發展,也沒有想到組織架構的設計會導致應用架構出問題。為此,CEO 做了一些調整,產品技術總監實線向電商部經理彙報,虛線向 CTO 彙報;總體來講產品技術總監對電商業務銷售端負責,CTO 對全公司 IT 架構管理和其他所有系統負責。經過善意的溝通,CTO 和產品技術總監的矛盾消除了,大家決定合力解決問題。

解決數據信息孤島的方法很簡單,那就是只保留一份客戶信息庫,這份客戶信息庫保存最核心的,與業務單元無關的客戶屬性和資料。至於積分、會員等擴展屬性依然由各個應用系統維護管理。調整後的應用架構圖如下:
[img]http://www.finereport.com/tw/wp-content/themes/BusinessNews/images/2017043013.png[/img]

將客戶信息庫獨立,商城、CallCenter 、CRM 和微信公共號通過統一介面調用 Customer Profile 存儲的核心客戶檔案,不論客戶或業務員從哪個埠查看或修改信息,變化對其他埠都是透明、實時的。實際上這就是客戶主數據管理 MDM(Master Data Management)的設計理念。

在企業應用系統建設中,不可避免的會遇到信息孤島問題,信息孤島是指因為各種原因,每個應用系統獨立建設時,沒有和外界系統做良好的打通,導致應用系統之間存在流程或數據的孤立性,最終給業務帶來嚴重影響。

解決數據信息孤島的經典方法就是主數據管理(MDM)的思想,主數據管理通過應用架構的拓撲設計,配合相應的管理手段,幫助企業存儲、識別唯一的關鍵數據,避免企業內部關鍵數據的冗餘和不一致問題。常見的主數據有客戶主數據,商品主數據等。

主數據管理的設計理念應該自始至終貫穿企業應用架構的設計過程。需要注意的是,企業應該在合適的階段實施主數據管理和治理。主數據將應用架構變得更複雜,在初期階段實施時需要投入更多時間和資源,而在企業發展的某些階段,快速迭代上線意味著對商機的捕獲和市場變化的迅速跟進,一個合格的架構師應該在應用架構設計和公司業務發展之間做出合理權衡,要根據現實的情況和資源,敢於在應用架構的和理性上做出妥協和讓步。

主數據經常作為底層數據應用來管理,因此在架構圖中我們將它和 DW 並列畫在最底層。
[img]http://www.finereport.com/tw/wp-content/themes/BusinessNews/images/2017043014.png[/img]

[b]抽離共性模塊全面服務化建設[/b]

公司業務發展穩定,各個系統底層做過幾次技術重構,性能更強健。為了讓各個應用系統更加聚焦,提升穩定性,節約開發成本,避免重複勞動,CTO 和產品技術總監討論後決定對一些公有服務從各自應用系統中剝離,統一進行服務化改造升級,為以後公司新業務的開展打好基礎。

例如,將 CRM 和商城後台的消息模塊功能合并,將商城支付模塊單獨剝離,設計實施了集成化的許可權管理系統 Auth,給全公司多個應用提供統一的許可權管理服務,控制公司運營風險。

CTO 和產品技術總監合作加強了數據團隊建設,設立了數據挖掘團隊,豐富了客戶畫像,加強了經營分析能力,產生了更多的策略輸出。數據策略輸出不僅給在線商城提供了更強勁的推薦策略,也為 CRM,運營人員提供了更豐富的策略運營、精準定向活動推送支援。
[img]http://www.finereport.com/tw/wp-content/themes/BusinessNews/images/2017043015.png[/img]

[b]強健的底層架構快速支援新業務開展[/b]

公司在尋找新的增長點,計劃開展個人理財業務。公司的組織架構有了新的調整,管理模式也有了新的提升,形成了集團化治理模式,成立了財務共享中心,人力資源共享中心。

新設立的理財事業部,和零售事業部、電商事業部一起,調整為獨立核算事業部編製,事業部聚焦經營和銷售,集團層面給事業部提供基礎運作支援。信息技術部也與時俱進,將之前的需求管理部調整為產品部,信息技術部主要負責 CRM、CallCenter、ERP、OA、HRM、DW、BI 等應用系統,保證集團職能部門運作,為事業部的應用系統提供基礎架構和底層服務支援。
[img]http://www.finereport.com/tw/wp-content/themes/BusinessNews/images/2017043016.png[/img]

因為集團IT應用架構已經非常強健,理財業務的系統構建可以迅速展開,CTO 和理財事業部的產品總監溝通後繪製了集團應用架構圖,理財業務只需要建設一套 C 端 APP 和一套基本的管理後台,而類似於客戶數據、支付、Push 服務、DW 和 BI 都直接使用集團現有系統,無需重新開發。
[img]http://www.finereport.com/tw/wp-content/themes/BusinessNews/images/2017043017.png[/img]

CTO 和產品總監討論後,認為上述架構圖還存在一點問題,賬號管理不應該單獨創建,集團已經有著很成熟的統一客戶管理理念,多套賬號管理模塊會再次造成信息孤島問題。因此決定將現有的賬號管理模塊也進行平台化、服務化升級,給理財業務提供支援。集團層面的 Passport 系統誕生了。

更新後的架構圖如下:
[img]http://www.finereport.com/tw/wp-content/themes/BusinessNews/images/2017043018.png[/img]

這裡順便解釋一下:為什麼本文對所有軟體系統都稱為系統,而互聯網公司則習慣稱其為產品。

互聯網的發展催生了產品經理的崗位。產品經理常分為 C 端產品經理,B 端產品經理(包括商家端和運營管理中後台)等。

B 端產品線中,有 CRM 產品經理、供應鏈產品經理等。在互聯網公司似乎不太在意區分產品和系統的叫法,到底兩者有何區別?

實際上,所謂產品是指企業提供的商品或服務,給企業帶來利潤。早期的互聯網公司多為虛擬經濟形態,面向用戶的軟體系統就是公司給消費者提供的商品或服務,因此聚焦軟體功能設計的人員被稱為產品經理。

而互聯網公司是一類高度依賴信息技術能力驅動業務的公司,對各類軟體系統都傾向於自主建設,因此不論是面向客戶的系統,或面向企業內部的系統,軟體設計人員都統一叫做產品經理,其職責定位就是負責軟體的設計和實現,軟體系統習慣被稱為產品;而在傳統企業,負責軟體設計的人員一般都叫做需求分析師或系統分析員,軟體系統習慣被稱為系統。

其實怎麼稱呼都無所謂,本文統一叫做系統。

[b]企業通用應用架構設計[/b]

[b]通用企業應用架構圖[/b]

對上文的應用架構圖做一些簡化和調整,以便更加準確的體現應用架構的共性以及與業務的對應關係,得到一張更加清晰簡潔的企業級應用架構圖。
[img]http://www.finereport.com/tw/wp-content/themes/BusinessNews/images/2017043019.png[/img]

第一層是對外系統。所有給企業外部客戶使用的系統都在這一層,包括官網,普通用戶或客戶使用的 C 端。如果是類似於美團,天貓這種平台性質的業務,還會包括給商家使用的商家端。這類系統站在與客戶接觸的最前線,是公司實現商業模式的橋頭堡。

第二層是對應 C 端系統的管理後台。常見的管理後台都會包含訂單、CMS 、商品等模塊。每個 C 端業務形態都會對應一個管理後台,有些管理後台的模塊可能會被抽離出來集中維護,例如風控,消息服務,客戶主數據。

第三層是業務單元支援系統。絕大多數企業業務的開展,必然不能單純靠線上的運作來實現經營,而可能包含電話銷售,客服,地推,倉配等一系列業務單元共同運作。業務單元的運作需要強大的系統支撐。

第四層是職能單元支援系統。企業發展到一定規模後,必然會有完善的職能單元作為後勤部門支援業務單元的運轉和企業的正常運作,例如法務、財務、人力、客服,每個部門的正常運轉都需要相應系統的支援。

第五層是基礎架構支援系統。信息化建設到達一定程度後,企業有必要將通用功能服務化,平台化,以保證應用架構的合理性,提升服務效率。這類系統主要給其他應用系統提供基礎服務能力支援。

第六層是數據底層。和第五層類似,這一層主要集中在數據層面的統一和封裝,對各個下游系統提供數據服務。

以上六層劃分涵蓋了企業所有的應用系統建設,每一個應用系統的存在都將定位在六層中的某一層。

上圖示例的系統涵蓋了絕大多數正常企業經營運轉常見的應用系統,在現實世界中,應用系統數量會遠遠多於上圖所示,例如商業銀行可能會有成百上千個系統存在。但是理解一個常見企業的組織結構,部門定位,以及上述應用架構圖形成的原因,可以讓你更準確快速的理解、掌握、設計任意一個應用系統。

[b]不同類型企業的應用架構圖示例[/b]

因為一般企業的組織架構設計,職能單元的設計基本沒有太大區別,而以上簡化版的應用架構圖映射了一個標準化企業的各個常規業務單元,且涵蓋了絕大多數企業中標準的應用系統,所以我們可以將不同互聯網企業的應用架構圖映射到上圖中。

下面我們用三個例子,向讀者演示不同業務形態、發展階段的公司,其應用架構的可能形態。作者並未在以下公司任職,或與相關內部人員探討過其公司應用架構,以下示意圖均為作者根據幾個公司的業務特點和發展階段,所做的推測。

首先以美團點評為例。
[img]http://www.finereport.com/tw/wp-content/themes/BusinessNews/images/2017043020.png[/img]

美團網的業務模式主要為供需平台建設,幫助消費者和服務提供方撮合交易。外部系統包括了 C 端系統和商家端系統,C 端系統為消費者常用 APP,商家端系統為商家提供商品管理、交易管理、推廣管理、經營分析等功能。C 端或商家端都對應後端管理系統,方便企業內部對整個平台進行管理、行銷、風控等。

平台需要發掘更多的商戶資源入駐,因此會有銷售過程管理的 OCRM 系統;平台需要對 C 端客戶提供客服與售後支援服務,相信美團點評的業務量,一套專業的 CallCenter 系統必不可少;美團提供了自營的配送服務,TMS 系統必然成為標配(也有可能是 SCM 中的模塊)。

由於美團業務不涉及自營的實物貨物買賣服務,沒有倉儲體系,因此推測沒有 WMS 系統(或者 ERP 中包含了 WMS 模塊但是沒有啟用)。O2O 業務需要管理大量線下門店,因此 GIS(Geography Information System)系統不可或缺,對於實力較強的公司,可能還會開發獨立的 POI(Point of Information)管理系統(也有可能是 GIS 中的模塊)。至於財務、OA 、Passport 、Auth、BI、DW、MDM 等,必然都是公司標配。

接下來再以今日頭條為例。
[img]http://www.finereport.com/tw/wp-content/themes/BusinessNews/images/2017043021.png[/img]

今日頭條構建了信息流資訊類 C 端,吸引網民使用,這類產品最常見的盈利方式為廣告變現。在公司經營之初,可能採取了市面上的 DSP 平台來完成 APP 的廣告管理(當然也可能從來沒有採用過),為了更好的設計廣告產品,相信現在一定有自己的廣告投放管理平台,因此公司會有給廣告主使用的B端廣告投放管理系統。

「當然也有可能還沒有這類平台,作者在百度工作時很多商業變現產品投放管理都是PM和廣告主線下溝通後通過內部平台操作的。」

因為業務模式以廣告投放為變現手段,因此後端系統可能沒有交易類後端複雜,但基本的 CMS 和風控(反垃圾、反作弊、合法合規)必然是有的。公司需要盈利,就需要售賣產品,售賣產品永遠不可能只在線上運作,必然會有 BD 團隊支援,因此今日頭條也會有 CRM 系統,管理對象為廣告主而不是網民。

但是 WMS、TMS 系統這類系統估計就不需要了。至於 CallCenter,筆者查詢了官網,沒有找到相關的客服熱線,猜測還沒有建設。

今日頭條的早已度過創業期,標準的管理軟體應該配備齊全,例如 OA、HRM;不同的基礎架構支援系統,在當前階段有可能有,也有可能沒有;例如 Auth、Pay、MDM 等。作為一個純技術公司,BI、DW 當然是標配。

最後的例子,我們挑一個相對規模小,產品形態單一的例子,例如墨跡天氣,萬年曆這類工具類應用的公司。
[img]http://www.finereport.com/tw/wp-content/themes/BusinessNews/images/201704302.png[/img]

這類公司在創業初期,不考慮變現的情況下,團隊小,產品簡單,應用架構圖也會非常簡單,在產品發布時,只需要實現官網、C端、後台管理、賬號和會員管理就足夠了。當然隨著公司的發展,常見的變現手段之一就是廣告投放,可能會繼續演變到類似於今日頭條的應用架構。

以上舉了三個例子,讓讀者更好的理解應用架構演變和公司業務模式以及發展階段的關係。在實際工作中,應用架構的建設與面臨的情況會複雜得多,只要理解了以上簡化版的例子,可以更容易理解實際工作中的場景。

[b]企業應用架構設計的一些建議[/b]

最後,我們來談一談如何合理的設計企業應用架構。不論是架構師,產品條線負責人,或某個系統的產品負責人,都要有架構設計的理念和知識,尤其是後端產品經理,必須充分理解企業應用架構的基本概念。這裡給出一些應用架構設計的建議。

[b]1. 系統定位和邊界要清晰,對應的業務定位和邊界要清晰[/b]

一套應用系統的存在,都是為了解決某一類業務問題,對應某一個業務板塊。如果業務板塊或業務單元定義模糊,也會導致對應的應用系統定位混亂。

[b]2. 系統要實現松耦合,高內聚[/b]

系統要對外界透明,簡單,易理解,與外部系統的介面要簡明,扼要,靈活。內部模塊高度聚合,粒度越細越不可拆解。

[b]3. 易變的,嘗試中的新業務要避免影響現有業務的穩定性[/b]

對新業務的支援,可以考慮新建獨立微小型應用系統,以便避免改造成熟核心系統,影響其穩定性和健壯性。

[b]4. 系統之間數據要實現單向流轉[/b]

系統之間盡量保證單向數據流轉,確保數據流可回溯,數據的一致性和可追溯性。混亂的數據流轉管理會造成應用架構管理的災難。

[b]5. 架構設計核心目標是支援業務,有些時候不合理的存在是合理的[/b]

應用架構存在的首要目標是支援業務,很多成長性企業或初創公司面對生存的壓力,不能為了保證架構的合理性而拖延系統實施速度導致企業錯過發展時機。

這種情況在互聯網型企業更為常見。業務還在試錯期,系統需要儘快保證支援業務試錯,如果一上來就談論整體架構的合理性,很可能花費巨大成本實現了合理架構後,新業務已經取消或失敗。優秀的架構師和CTO要懂得在合理架構設計和靈活多變的業務發展之間做出智慧的權衡取捨。

對於 CTO 或公司架構師,要保證整體企業應用架構的合理性,只要大框架合理,局部的偏差可以忽略,修正的成本也比較小,如果大框架有偏差,修正的代價會非常高。對於產品條線負責人,要保證局部框架的合理性,避免出現設計不合理造成的返工和補救工作。

很多時候架構師或條線負責人要做出判斷,是做一套新系統,還是修改老系統;新系統如何定位,老系統如何調整定位;數據如何流轉,系統之間如何關聯,底層數據如何打通;是否要復用其他系統模塊,是否要將某些模塊抽象化,服務化,平台化。對於產品經理,要在系統級別的粒度做出類似問題的判斷,能夠識別出可能存在的系統演變風險,及時升級控制不了的問題,避免做出錯誤決策。

企業架構是一套龐大複雜的體系,本文是對其中應用架構部分,結合作者實際工作經驗的淺薄理解,業界有著眾多的企業架構建設規範和指引,例如 Zachman、EAP、TOGAF 。這些框架涵蓋了信息技術和企業戰略結合實施的方方面面,感興趣的讀者可以做更深入的學習。
—————————————————————————————————————————————————————–

[i]文章由[b]FineReport[/b]報表與BI商業智慧軟體分享。

作者:楊堃(微號公眾號:goYangKun),9年互聯網研發、產品設計經驗,曾就職於傳統外資保險公司,百度,現就職於美菜網。[/i]

回復族名卻遭公務員勸退:族名是認識原住民的開始,社會應更友善!⎪暨大原青在說話

週五, 四月 28. 2017

回復族名卻遭公務員勸退:族名是認識原住民的開始,社會應更友善!⎪暨大原青在說話
BY 讀者投書 · 2017/04/24

Credit: Sakinu KazanilanCredit: Sakinu Kazanilan



「你知道你⾃己是誰嗎?」

在去(2016)年 7 月,我去改回了我原本的名字,我魯凱族的本名。

在讀原住民專班,接觸了種種⾃己的身分事務,才知道我不是「顏皓庭」,我是「Pukihinga Lapalave」。



以前的我,只知道我是魯凱族,在平地讀書,好想跟漢⼈一樣很會讀書、好有錢,爸爸媽媽也要我多跟平地人做朋友,要我學習他們,這樣以後才能賺大錢,才有很好的生活。以前聽起來很好聽,現在想起來好諷刺。但這也不能怪我們爸媽,在他們那個年代,就是這樣跟隨主流社會,能站穩、跟上,就等於好生活來了,但這些是爸媽不希望我們過得比他們辛苦。

那是以前的我,現在我是魯凱族人, 雖然身體都在主流社會,但⼼卻都在部落。



族名是證明身份的最好方式

我是 Pukihinga Lapalave,魯凱族的命名法,其中 Lapalave 在現代稱為「家屋名」。在魯凱族以前的生活,每一個石板屋、每一個家,都有⾃己的名字,像我的家就叫 Lapalave;而 Pukihinga 是我男性長輩傳給我的名字,是貴族的名字。所以我的魯凱族全名 Pukihinga Lapalave 是「名字」+「家屋名」。

在部落,當 kaingu(祖母輩)問我「你是誰」,我回「我叫 Pukihinga 啊!」

Kaingu:「哪一個家的 Pukihinga?」
我:「Lapalave 的。」
Kaingu:「噢,你是誰誰誰的兒⼦齁!來,kaingu 摸摸看你。」

這就是我們命名的方式,也是過去生活中,人們認⼈的方式。



改回族名是我認為最好證明自己是誰的方法,而且 16 族裡,每一族都有自己的命名方法,每⼀個名字都是特別、都具有意義的。

例如泰雅族自己的名字後要接父親的名字,這就是他們的命名方式。如 Yukan Cinto 的 Yukan 是自己的名字,Cinto 是爸爸的名字,這樣在部落被問到「你是誰」,即便不認識你,也可以從你爸爸的名字知道你是誰家的小孩;如果還是不知道,問到了爺爺的名字,長輩就大概知道你是誰的孫⼦了。



興奮恢復族名 公務員卻試圖勸退

不管音譯或拼⾳,都只是記載我們語言的工具,最終還是要能真正願意去了解台灣這美麗的 16 族。命名很神奇,也是族群⽂化中很重要的一部份,但在恢復族名的路上卻有很多的歧視、不便,或很多的限制。

記得好清楚,在我恢復族名的那一天 —— 我應該換了三個服務我的⼈ —— 每個人都說不會辦理恢復族名!本來興致滿滿地要去恢復,但卻發現恢復族名好不被重視,也好不普及,甚至⼀開始還勸我說:「改族名很⿇煩喔!你還要去改健保卡啊、⼾頭名字⋯⋯」巴拉巴拉一堆,就只希望我打退恢復名字這念頭,即便我做好了萬全準備去恢復族名,當下真的好生氣!

當我要證明我自⼰是誰的時候被攔住,請問你們是我嗎?為什麼要這樣勸退我?



在恢復魯凱族名字到今天,每一天都充滿了好多興奮,即使遇到了很多地雷,但也有很多人因此而認識我,認識我的魯凱族 —— 改回族名是我的第一步,因為對我來說,不管音譯或拼⾳,都只是記載我們語言的工具,最終還是要能真正願意去了解台灣這美麗的 16 族,而不是認為我們都是一樣的,以為開一些管道,就等同於認識我們原住民族。




⾝為原住民的我的朋友們,希望你們看到這裡,會開始想去恢復族名,這也是更認識⾃己的開始。

也希望漢⼈朋友,快點去認識你們身邊的原住民朋友;認識我們,讓在這片⼟地上的每個人都知道真實的我們,⽽不是以為認為原住民就只有一族。

我愛你們。





延伸閱讀

還在重蹈國民政府71年前犯下的錯?尊重原民不只修法,更要修掉那些毫不尊重多元文化的腦袋
別再問我姓什麼了,因為我就沒有「姓氏」嘛!


關於作者

Pukihinga Lapalave,來自屏東縣霧台鄉大武部落,是一位魯凱族青年,現就讀國立暨南大學⼆年級。從⼩沒有離部落太遠,直到上了暨南大學原住民專班,開始關注族群事務,才知道自己的身份有多麼特別,也希望⾃己能為原住民發聲,讓⼤家認識我們。

喜歡影像每一刻的情境與情緒,認為影像能傳送不一樣的訊息。希望未來能⽤影像傳遞原住民族的正確訊息給大眾。

作者臉書:https://goo.gl/g64GGh


照片攝影作者為 Sakinu Kazanilan,漢名林哲潁,是賽德克族與排灣族的原住民,目前是國立暨南國際大學原住民專班學生。

身為從⼩就在⼤自然擁抱下成長的原住民⼩孩,我喜歡影像 —— 希望將來有一天能透過影像,帶給更多人不一樣的故事與啟發。

作者臉書:https://goo.gl/xT1P9c


專欄介紹:【暨大原青在說話】

為鼓勵新一代原住民為自己發聲,本專欄嘗試與國立暨南大學原鄉發展學士專班合作。

位於埔里的國立暨南大學原鄉發展學士專班,其學生均為來自各地不同族群之原住民,希望培育想回部落服務的原住民青年,也期待他們成為日後原住民自治的人才。

暨南大學原專班課程包含了台灣原住民史、原住民社會與文化、當代原住民議題、部落營造與規劃、原住民文學、原住民生態知識、原住民影像、部落地圖與傳統領域調查、部落工作實習、基礎族語(已開設六族)等,同時亦請部落族人親臨校園指導學生各項實作,如種植小米、建築賽德克族傳統穀倉、泰雅竹屋、學習織布、製作漂流木椅等,課程均開放校內非原住民學生一起學習。大二開始分為「社會工作組」或「觀光文創組」,選擇「社工組」的同學畢業後可以成為社工員或考社工師執照,服務自己的族人;選擇「觀創組」的可以從事「有原住民特色的觀光或文創產業」,協助部落打造友善環境的文化產業。

粉絲專頁:暨大原鄉發展學士專班

科博館敦煌再現 1:1莫高窟震撼視覺

週五, 四月 28. 2017

科博館敦煌再現 1:1莫高窟震撼視覺
\
2017-04-26 14:45聯合報 記者喻文玟╱即時報導



不必去大陸,到台中就能看到敦煌的神秘與瑰麗。暌違18年,國立自然科學博物館推出「敦煌風華再現:續說石窟故事」特展,為期5個月,館方把2座敦煌石窟原封不動複製到現場,還有壁畫、彩塑藝術,現場有VR體驗區,讓觀眾能親自在石窟裡飛簷走壁。

科博館曾在1999年舉辦《敦煌-沙漠中的明珠》展覽,當時與聯合報系合作,短短半年展期,參觀人數高達55萬人次!歷經了18個寒暑,這次科博館自己策展,隨著科技日新月異,展覽結合VR虛擬實境,讓觀眾直接走進3D敦煌世界。

敦煌研究院名譽院長樊錦詩特別出席展覽開幕,她研究敦煌54年。樊錦詩說,敦煌是一段跨時空的歷史,前、後持續1000年的創作,當時絲綢之路繁榮了1000年,中、西文化交流,催生敦煌。

特展最值得欣賞的一景是「藏經洞」,它在1900年被王圓籙道士發現,至今已研究了100多年還有說不完的故事。

「藏經洞」的文物都是手抄寫本,除了經書以外,還有道經、儒家經典、小說、詩賦、史籍、地籍、帳冊,是重要的一門「敦煌學」,最可惜的是,當時發現後國外的考察團包括英、法、俄羅斯、日本陸續「洗劫」,原本有5萬多卷剩下8000多卷,文物散佚是一種浩劫,在民國初年觸發知識份子張大千、于右任對文化保存的覺醒。

策展人、展示組主任何恭算指出,特展另一個特色是有2座1:1複製洞窟,莫高窟275號、220號,原汁原味呈現壁畫、塑像,275號建於北涼時期,220號是初唐時期,兩者風格差異很大,觀眾進入洞窟,就像走進莫高窟的感受。

科博館也把第158號「涅槃窟」位於莫高窟南端,原長15公尺的臥佛,以13公尺比例複製到科博館,是莫高窟最大的一尊涅槃像,相當壯觀。現場還有41幅臨摹壁畫,15尊珍貴塑像。

「敦煌風華再現」主展場票價180元,多媒體展區票價50元,購主展場票者可以20元加購多媒體展區,展期至10月1日。

Re: [ 作業06] jQuery動態換頁效果

週四, 四月 27. 2017

(1)作業網址:http://mepopedia.com/~css105-2b/hw06/hw06-1045445089
(2)製作心得:jquery(tu)(tu)高解析度照片要找挺久的:P大致上還行(tu)

《 #報導者》第一本調查報導專書:《 #血淚漁場》】

週四, 四月 27. 2017

《 #報導者》第一本調查報導專書:《 #血淚漁場》】

2016年12月19日,《報導者》推出年度調查報導──《造假.剝削.血淚漁場》,與印尼知名調查媒體《Tempo Magazine》跨國聯手追蹤印尼漁工之死真相,揭發台灣遠洋漁業稱霸世界背後的醜聞,省思台灣身為海洋國家的角色與責任。

報導刊出後,不只促使主管機關農委會回應,行政院長林全也在院會中要求健全漁工勞檢機制,屏東地檢署更立即宣布重啟調查印尼漁工死亡案。漁業署今年也提高外籍漁工的基本薪資,並決議每年辦理仲介評鑑。

今年,記者群更持續追蹤,在4月完成《血淚漁場──跨國直擊台灣遠洋漁業真相》一書,進一步完整描繪台灣做為海上王國的歷程、遠洋漁業如何影響他國及數萬家庭,揭露第一線海上工作者的心聲;我們也分享跨國媒體聯手調查的過程,希望傳承經驗給對跨國調查報導有興趣的朋友。

《血淚漁場》由行人文化實驗室出版,這是漁船甲板上的血與淚,也是記者調查真相的字字血淚。好書,不買嗎?

敦煌情緣,情繫千年

週四, 四月 27. 2017

敦煌情緣,情繫千年

「敦煌風華再現-續說石窟故事特展」開幕

【媒體參考稿】



敦煌風華,科博再現!科博館主辦、敦煌研究院合辦的《敦煌風華再現-續說石窟故事特展》,為臺灣歷來最大規模的敦煌文物展。科博館館長孫維新、敦煌研究院名譽院長樊錦詩、財團法人國立自然科學博物館文教基金會楊冬青董事及陳景松董事等貴賓今(26)日共襄盛舉開幕式。展期今日起至106年10月1日,全臺僅此一場,以敦煌石窟建築、壁畫、彩塑藝術及藏經洞之珍貴文物為主,還有一尊長達近13公尺的莫高窟涅槃臥佛。主展場票價180元,多媒體展區票價50元,購主展場票者可以20元加購多媒體展區,歡迎踴躍參觀!



特展集結敦煌石窟不同時代、洞窟與內容的作品,打造出敦煌石窟藝術的縮影。結合科技的雙展區,還有VR體驗等豐富的多媒體互動內容。配合這次專題展覽,除有專業教育人員進行導覽解說外,也將舉辦系列的教育和演講活動。今日下午3時由樊錦詩院長於科博館紅廳進行一場講座,講題為「敦煌莫高窟及其文化價值」。



科博館曾在1999年舉辦《敦煌-沙漠中的明珠》展覽,短短半年展期,參觀人數高達55萬人次!歷經了18個寒暑,敦煌石窟不論在學術研究或是壁畫洞窟的保存維護上都有長足的進展。為使民眾有機會再次一窺敦煌文化藝術寶藏,科博館特別籌劃這項展覽,精選有別於前次展出之洞窟、壁畫、塑像與文物等展品。展覽分為二個展區:主展場位於第四特展室及其外部陽光過道南邊;多媒體展區在立體劇場旁廣場。



主展場規劃六大主題,首先以敦煌的歷史、地理與地質為序,再探石窟分佈、開鑿過程與建築形制。第三單元將展示石窟內的藻井、邊飾與花磚等建築裝飾,然後進入以壁畫、塑像和複製洞窟為主的精彩主題內容。第四單元介紹石窟內的寶藏,呈現藏經洞所發現的經書、文獻與文物。第五單元陳述敦煌石窟歷經的浩劫與重生歷程,敍說敦煌石窟如何從無人管理的狀態,發展成現今世人研究中古時期文化的重要藝術寶庫。最後第六單元著重在石窟之修復與保存,並敦請臺灣師範大學張元鳳教授協助建構壁畫臨本修護工作室,讓民眾瞭解修復的工序、成果及其重要性。



展出的重要展品涵蓋了敦煌石窟的主要內容類別,包括大型涅槃佛像、分別建於北涼和初唐二個不同時代的複製洞窟、栩栩如生的彩塑臨本、敦煌研究院兩位前任院長常書鴻先生及段文杰先生等人所繪的精彩壁畫臨摹作品,以及珍貴的佛教經卷、回鶻文木活字粒、絹幡、西夏文諸密咒要語、西夏文普門品等敦煌文物,充份彰顯敦煌文化涉及的廣闊層面及其所隱藏的精髓內涵。



  多媒體展區除播放敦煌石窟相關影片外,配合這次展覽特別發展壁畫著色與拼圖遊戲,藉由這些互動多媒體,讓參訪者更加認識敦煌壁畫的深奧內涵,以達寓教於樂的目的。近年來廣受歡迎的虛擬實境(Virtual Reality, 簡稱VR)技術,也應用在這次的展覽當中。展場內引進臺灣大學洪一平教授與敦煌研究院合作多年研發的莫高窟第61窟,以及政治大學黃心健教授發展的莫高窟第285窟的VR影片,讓觀眾有如身歷其境般地進入一個沉浸式的 3D 世界,感受更深刻活潑的學習體驗。

  

更多照片與音檔請參考:

https://drive.google.com/drive/folders/0BxEjCFXjkjKSeVA1RFdOWk9pTEE



新聞聯絡人

國立自然科學博物館 黃星達 04-23226940#365/0910-586689

Re: [作業05] jQuery動態網頁初探-fadein

週四, 四月 27. 2017

(1)作業網址: http://mepopedia.com/~css105-2c/midterm/midterm-1045445033
(2)製作心得: 還蠻簡單的,效果又不錯滿合胃口的

Re: [作業03] HTML與CSS練習--1.資料整理--以DIV製作表格效果。2.其他頁面完成

週四, 四月 27. 2017

(1)作業網址:http://mepopedia.com/~css105-2a/hw03/hw03-1045445218/index.html
(2)本頁設計重點: 推薦VIXX
(3)製作心得: 學習到很多
學號 1045445218

Re: [作業02] HTML與CSS練習--首頁實作篇

週四, 四月 27. 2017

(1)作業網址:http://mepopedia.com/~css105-2a/hw02/hw02-1045445218/index.html
(2)網站主題/網站名稱: - R e a l V ! V . I . X . X VIXX!-
(3)分類項目(導覽列):
首頁
成員簡介
專輯
MV
外部連結
(4)對象: 喜歡韓國團體
(5)色彩計畫: 黑灰藍
(6)風格設定、網頁看點、預期成效:
(7)製作心得: 慢慢熟悉中

Re: [作業01] DIV與CSS複習--以色塊為主的基本單欄網頁版型 (新增CSS3練習)

週四, 四月 27. 2017

1.網址:http://mepopedia.com/~css105-2a/hw01/hw01-1045445218/
2.設計概念與製作心得: 以住宿做此設計概念 做出來還不錯 努力學習
3.何謂HTML、DIV及CSS:
HTML是網頁的基本架構
DIV是針對小型的地方設計使用
CSS是風格設計用的語法
4.附上至少一個覺得設計很有質感的網站,並說明原因
5.期待這門課的學習成果與收穫為何?

Re: [期中作業] HTML與CSS應用--網站實作

週四, 四月 27. 2017

(1)作業網址: http://mepopedia.com/~css105-2a/midterm/midterm-1045445218/index.html
(2)網站主題: VIXX
(3)導覽列選項/分類項目(對應檔名): 首頁(index) 成員簡介(Untitled-1) 專輯(profile) MV(works) 外部連結(link)
(2)設計對象: 喜歡韓流的朋友
(3)色彩計畫: 使用藍色黑色 白色為主
(4)風格設定、預期成效: 感覺還不錯 高冷風
(5)製作心得:剛開始不太上手 一直在觀摩大家的作品 找出重點 到後來越來越順手