建築邊線:銳+ Adobe AIR的教訓
2009年3月31日,9:52上午由乍得友誼|在發展 , YUI實現 | 13評論作者簡介: 乍得的友誼是一個前端工程師,與雅虎口碑營銷團隊的工作。 一個長期的開源貢獻者,他最近幫助啟動MiaCMS項目 ,Mambo的下一代叉建成使用YUI。 在這篇文章中,他引導我們通過發展與YUI的Adobe AIR平台上的桌面應用程序的過程。
有沒有想過什麼人說現在的公司,品牌,服務,產品,等等? 副業 ,最近在雅虎內部的黑客項目的啟發,超出標準的顧客調查的過程中去,讓你實時聽人談論你的產品,然後使用該反饋,以提高您的服務或幫助用戶與他們的問題。
簡單地說,我們項目的目標是
- 創建一個桌面應用程序,允許對Twitter的高級搜索查詢的建立,分組和自動執行
- 充分利用現有的技能集和工具
- 針對在Windows,Mac OS X中,Linux操作系統,並盡量減少必須編寫特定於平台的代碼量
- 開放的源代碼,讓其他人可以借鑒,促進和/或延長他們認為合適的產品
我們的前端工程師團隊中的JavaScript,CSS,HTML,PHP的專家,但沒有很大的開發桌面應用程序的經驗。 所以成為問題,如何最大限度地發揮我們現有的技能集桌面開發? 我們的答案是利用Adobe AIR平台 ,“讓開發人員使用成熟的網絡技術來構建富Internet應用程序以外的瀏覽器上運行多個操作系統”。 AIR支持HTML / JavaScript開發(除了Flex和Flash)以來,我們對傳統的網絡技術可以建立我們的應用程序,頂端銳 ,它的三個主要桌面操作系統上運行。
在AIR銳網格
副業包含YUI庫的廣泛實施。 它應該有希望作為為其他有興趣嘗試使用YUI和Adobe AIR開發的很好的例子。 使用YUI的網格構造應用程序的佈局,甚至使用了最近加入的唱腔廣場角色 。 電網工作非常出色的空氣環境中,並重新設計發生發展中容易實現用最少的代碼改變。 就像在標準的瀏覽器環境,YUI的網格可以作為一個AIR應用程序的基礎,即使開發人員決定對使用其他JavaScript庫,而不是選擇另一個框架。
YUI組件在AIR
除了 電網,副業也利用DOM , 事件 , 拖動和Drop , JSON , 選擇 , 集裝箱 , 按鈕 , 菜單 , 滾動條, TabView組件。 我很高興向大家報告,所有YUI組件的表現極為出色的空氣環境中,無需修改。 副業不落實相當定制設計,因而需要一些定制皮膚的YUI組件,但沒有核心的修改。 最AIR應用程序往往有豐富的桌面應用程序的感覺。 對於這一級別的定制, YUI剝皮文章是一個很好的參考上手。
除了瀏覽器
超過傳統的網絡環境中的Adobe AIR平台的一個重大改進是本地SQLite數據庫和用戶的文件系統的訪問。 本地數據庫訪問變得更可在傳統的Web環境中,通過技術,如齒輪和HTML 5客戶端存儲,但現在這些解決方案是不是無處不在。 對於那些有興趣在AIR開發,農副產品先後攻克了許多的共同任務,是一個典型的AIR應用程序可能需要,例如,獲取外部數據處理應用程序更新,與本地數據庫進行交互,與本地文件系統的工作,推行母語瀏覽器窗口,顯示桌面通知,等它應證明在這方面是一個有益的參考。
AIR開發的竅門
- 知道你的環境。 AIR使用WebKit開源瀏覽器引擎罩下。 傳統的Web開發的目的是使盡可能多的瀏覽器/操作系統的跨應用程序或網站的工作。 支持哪些瀏覽器通常可以歸結為成本與使用因素。 然而,編碼為一個單一的渲染引擎,減少需要準備和測試,對市場潛力組合極多。 話雖這麼說,但它仍然是有意義的跨瀏覽器的方式,在可能的情況下發展,因為有可能來的時候,應用程序需要尋找到一個更傳統的瀏覽器環境的方式。 使用像YUI的框架將使這一過程相對輕鬆。 它是簡單的瀏覽器和目前由YUI的支持平台,通過分級瀏覽器支持圖表 。 開發人員應該相當安全,建立AIR應用程序(使用
-webkit-border-radius圓角微風)時,採取一些基本的快捷鍵,但他們有節制地使用,並記錄他們,所以他們很容易被發現後。 - 在一個複雜的應用程序在任何環境中發展的堅實的調試工具集是一個必須擁有的。 Adobe提供了一些有用的工具,調試盒的空氣。 開發人員應該調查的AIR調試啟動器(ADL) , 在HTML的Introspector , HTML源代碼查看器 。 除了 捆綁工具的Aptana Studio中與它的Adobe AIR的插件被證明是一個不可或缺的資產。 在Aptana插件創建AIR項目提供援助,導入常見的JavaScript框架,調試,包裝/出口,以及數字簽名的應用程序。
- 不要忘記我們已經從標準的瀏覽器環境中(即,優化你的圖片,縮小和組合應用程序的CSS和JavaScript文件,沉重的基於事件的應用,如農副產品,利用優勢學到的性能技術事件代表團技術 ) 。 AIR應用程序運行在桌面上,並因此有是多一點與性能寬大比,典型的瀏覽器環境中,但瀏覽器本身一樣記得,在空氣容器也消耗甚至在應用程序的自定義代碼踢在之前系統的內存塊。
未來之路
副業的beta版本,可以安裝在http://sideline.yahoo.com 。 該代碼是開源BSD許可證的條款下,在GitHub上 。 我們歡迎捐款,反饋,和/或建議。 此外,在保持盡可能開放的東西,支持新興技術的精神,我們將可能移植邊線以鈦在不久的將來。 端口上已經做了一些初步的工作,並會繼續在未來數週。 這也是完全可能的副業,將最終實現如JavaScript的ORM JazzRecord ,以紓緩跨平台的數據庫交互。 如果任何人有額外的提示,支持多種平台,我們很樂意聽到他們的聲音。
現在出去和叉 !
共享和擴展: 書籤del.icio.us Digg它! | reddit!
實施重點:DocLanding
2009年3月30日,10:24上午由埃里克·米拉利亞在YUI的實現 | 1條評論
托德Fishback總統DocLanding ,基於Web的文檔管理解決方案。 托德,加入YUIBlog討論他的團隊的內的DocLanding的用戶界面,選擇YUI的工具和部件。 你可以了解更多有關,從DocLanding 介紹其在2008年秋季演示會議 。
告訴我們一個關於DocLanding點點-為用戶解決的核心問題是什麼?
DocLanding是對需求文檔管理解決方案,提供企業級文件管理功能,為大多數企業解決方案的成本的一小部分。 通過我們的軟件作為服務(SaaS)提供或作為內部系統,該軟件可以交付。 我們的客戶主要是在金融服務和醫療保健領域。
我們為我們的客戶解決的共同問題,包括提供一個基於網絡的分佈式勞動力集中的存儲庫,基於網絡的按需掃描用紙量低辦事處,並在高用紙量辦事處基於桌面批次的掃描。 我們解決其他問題,包括安全的文件共享和協作,文檔編輯/註釋,版本控制,文檔註釋,和文檔水印。 我們獨特的方法來單獨控制,但鏈接的文檔庫,使用戶能夠訪問不同的資料庫,一個共同的登錄。
什麼是您的產品設計提出特定的用戶界面的挑戰呢?
我們從一些早期的工作,你根本不能低估了人性化設計的重要性。 創建一個網站是很容易,但建立一個真正的Web應用程序,以滿足企業家的需求,是真正的工作。 我們的產品,試圖從文件管理嚴格的大型企業的域名,並提供給任何小型企業。 電子文檔管理,其核心是不是一項簡單的任務。 我們的目標是組織和控制,除了使他們完全可搜索大量文件的訪問。 正因為如此,用戶界面實際上是歷來花費大多數的開發時間。
我們發現,你將節省時間和金錢上的支持問題,當你讓你的網站簡單,容易使用。 該部放寬運行網站所需要的規格。 我們得到了我們減少到幾乎任何現代瀏覽器的JavaScript和Flash。 我們想出了核心站點設計提出了非常具體的屏幕房地產使用其自身的挑戰。 我們發現我們的用戶能夠更好地使應用程序充分利用,當我們重視的顏色,肖像和其功能的控制接近。 我們認為我們是在正確的軌道上,因為我們的反饋頁面返回更多的附加功能請求,請求幫助。
你選擇了YUI的力量來幫助你的網站。 是什麼促使你該決定?
答案很簡單,一致性和速度。 我們需要一個框架,使我們能夠滿足我們的產品設計規格。 更具體地說,我們有雄心勃勃的設計目標,如維護一個屏幕視圖和減少或消除整頁回發。 此外,我們希望我們必需的元素,許多不同的瀏覽器的外觀和功能相同的,因為我們可以管理。 瀏覽器和渲染方法之間有足夠的一致性問題,已經抗衡,所以我們選擇需要的瀏覽器特定的編碼,我們就必須這樣做,以盡量減少金額的任何框架。 在嘗試了各種不同的工具包,銳來到上面很清楚的。 有一個位的所有產品的學習曲線,但YUI的最好的回報。
基本框架並不需要一個插件,它起著很好。NET中,腳本輕,緊實。 一旦我們得到了掛起的框架中,我們發現它啟發YUI的版本比較舊的傳統界面頁。 在任何情況下,調整我們的UI方法返回打火機下載我們的客戶在性能和一致性的巨大收益。
YUI組件您使用的是最嚴重的在您的應用程序?
我們實際上使用相當多的部件很多。 最有利的是那些允許我們這樣做,並盡可能在一個屏幕上,所以盡可能多的TreeView , 菜單 , SimpleDialog和佈局管理一直非常有用的。 事實上,我們幾乎所有的控制,但我們特別感謝上傳控制的能力,處理多個文件選擇。 一段時間,我們一直在尋找解決這個問題,YUI的一直是我們迄今為止所遇到的最優雅的。 我們利用好JSON實用程序和連接管理器,大大減少我們做,這使我們的足跡,更重要的工作,不等待,讓我們的用戶向服務器請求的大小和數量。
什麼DocLanding下? 什麼是你的工作,以解決在即將發布的挑戰?
我們正在不斷努力改善我們的產品的功能集。 我們的用戶要求的功能,更好地整合與主應用程序的編輯他們的文檔,所以我們會讓時間。 我們的工作更好地適應大文件上傳。 否則,我們在桌子上有幾個想法,我們正在權衡哪些是最適合我們的用戶受益。 一個版本是為手機和上網本優化的網站已經在設計階段,以及工具導入結構文件夾從桌面直接進入DocLanding。 實驗中,我們只存儲在網站的元數據和拉動的內容直接從網絡客戶機運行我們的軟件的想法玩弄。 最終,我們的用戶的需求,將決定我們什麼方向移動下。
共享和擴展: 書籤del.icio.us Digg它! | reddit!
為Flickr銳自動完成建設快速人民的搜索
3月26日,2009在8:59由羅斯Harmes上午| 開發 | 1評論在Flickr的 ,我們最近增加了一個新的人選擇的部件到我們的網頁數;此功能是基於YUI的自動完成控制 。 人民的選擇部件,使我們的成員從他們的聯繫人名單中選擇個人,它可以包含20,000項以上。 由於大量的數據,獲取和分析數據的傳統技術是不可行的,這主要是由於極慢解析倍。 在這篇文章中,我們將看看一些不同的數據格式,我們嘗試在自動完成配置,我們發現是最高效的。
首先,這裡有一個視頻回顧一下我們試圖完成什麼;右邊描繪新的互動與人發現者部件:
XHR和自定義數據獲取和分析:
最大的挑戰是找到一種數據格式,這將是快速下載,快速解析, - 高於一切 - 安全。 我們第一次嘗試XML和Ajax,但XML解析被證明是非常慢 - 事實上,我們發現,這種做法可能帶來更大的數據集上的瀏覽器。 接下來,我們嘗試了JSON和Ajax結合,這是速度明顯加快,但它仍然花了80秒以上來解析我們最大的數據集(大約10700對象,每個數組包含幾個屬性)。
最後,我們發現了兩個運輸/解析技術,原來是非常快:
- 獲取JSON(包裹在一個回調函數)使用動態生成的腳本標記;
- 解析自定義的數據格式(控制字符分隔的列表)使用
split()獲取與Ajax(使用YUI連接管理器 )。
最後,我們去自定義格式。 格式化我們的JSON,以便它可以由一個動態的script標籤執行的是一個不太安全的方法,而不是性能取勝。 使用XHR給了我們一個更安全,還是很高性能的解決方案。
用戶交互:YUI的自動完成
一旦我們有辦法迅速進入JavaScript的數據,下一個挑戰是創建一個用戶的方式,通過聯繫人列表中快速搜索。 要做到這一點,我們把YUI的自動完成控制。 完全滿足我們的需要: 速度極快,非常容易配置。 使用它與我們的自定義數據,我們創建了一個功能,使用自動完成實例的DataSource;在widget的每一個按鍵觸發此功能,並在搜索字符串傳遞。 在這個函數中,我們遍歷所有成員的聯繫,並嘗試以四個不同領域的查詢相匹配。 我們使用正則表達式做字符串匹配。
即使對於大型成套的接觸,我們發現這是非常有效的技術。 這裡是我們所做的基本版本:
功能searchContacts(查詢){ VAR比賽= [] queryRegEx =新的正則表達式(查詢,'我'),/ /查詢應 / /前檢查 / /使用正則表達式。 聯繫; (N = 0,LEN = contacts.length; N <LEN,N +){ 聯繫=接觸[N]; 如果(contact.username.search(queryRegEx)== -1 | | ,!contact.realname.search(queryRegEx)== -1 | | ,!contact.emailAddress.search(queryRegEx)== -1 | | contact.alias.search(queryRegEx)== -1){ matches.push(接觸); } } 返回匹配; }
一旦有了小部件連接到的數據,我們做了一個改變默認的自動完成配置:我們的queryDelay參數設置為0 (默認值是200毫秒)。 這意味著按一個鍵,並正在發起一個搜索之間不會有延遲。 (自動完成顯示器往往閃爍了一下,如果你在連續快速輸入幾個字符)也有缺點,但我們發現它是單一最大的改進我們所做的,甚至比我們的搜索功能的優化更重要。 雖然queryDelay為200ms或更可能是更適當的XHR或其他遠程數據源,我們發現,我們的正則表達式為基礎的數據源與本地數據是尋找每一個按鍵上的任務。 與自動完成,我們得到了免費的緩存添加到組合,使任何給定的搜索將只進行一次。
所有這些技術,包括不同的數據格式和廣泛的分析數據,為每一個細節上的更多細節,可以發現上code.flickr博客。
共享和擴展: 書籤del.icio.us Digg它! | reddit!
在2009年3月25日,野生
2009年3月25日,9:08上午由YUI團隊|在野生 | 3評論注意到,在過去的幾個星期,從YUI社區新聞。 讓我們知道我們錯過了什麼,我們會得到下一次的意見:
- 羅斯Harmes YUI的自動完成和Flickr的人民搜索 :Flickr的羅斯Harmes Flickr的代碼博客上有一個有趣的一塊做超快速搜索建議在創建Flickr的人民搜索功能。 羅斯在詳細討論的過程中,他使用迅速處理客戶端上的聯繫人名單,讓他們為JavaScript。 從那裡,他轉向珍妮·唐納利的YUI的自動完成 :“[]數組在JavaScript接觸中,我們需要一種方法,通過搜索,並選擇一個。 對於這一點,我們使用YUI的優秀自動完成構件。 進入小部件的數據,我們創建了一個 DataSource對象,將執行一個函數,得到的結果。 此功能只需通過我們的聯繫陣列環匹配給定的查詢,對每個聯繫人的四個不同的特性,使用正則表達式(RegExp的對象竟然是非常非常適合與平均搜尋時間為10000未來的情況下接觸,在38ms以下)。 結果被收集後,自動完成構件發生的一切照顧,包括緩存的結果。“
- W3C的測試站點使用YUI Reset和字體 : 尼科爾沙利文寫道告訴我們, YUI的復位和字體是新的W3C的重新設計網站,你可以在這裡預覽的一部分。 該網站還利用尼科爾的光正交碼的工作。
- 凱洛格的巴西與YUI的連接,動畫,內置的網站 : 凱洛格的巴西網站實現各種YUI組件。 我們注意到, 連接管理器 , 動畫 , 獲取 ,更多的,通過一個單一的組合長柄yahooapis.com網址。 很高興。 ( 原始來源。 )
- 銳瞄準- Greenbookings.com,可持續旅遊網站 :伊沃Schaap寫信告訴我們Greenbookings.com ,最近推出的旅遊網站,重點是可持續旅遊的新興世界。 當你通過Greenbookings預定,他們將caclulate,並允許您以抵消您的旅行所產生的碳足跡。 伊沃寫道:“我已經工作了很長的時間和昨天發布我的新網站greenbookings.com ,幾乎每一個模塊中使用的框架:日曆,製表符, DataTable中 , 歷史+間隔日曆 ,電網與YUI框架,自動完成的,更多的人。 還多的努力已經度過一個非常快速的頁面加載,從頭部到頁面底部卸下所有的javascript。“我們喜歡的網站和使用,約翰Peloquin的貢獻銳, 間隔日曆日期選擇 。
-
銳瞄準-無限填字遊戲網站 :馬爾科EGLI中寫道,向我們講述了無限的填字的新版本,使用YUI的公用事業和部件的各種各樣的遊戲網站。 “上週五發布了新版本的無限填字 。 這是英文的第一個版本。 它是一個無限的字謎,完全在瀏覽器中運行。 好幾個不同的YUI組件被用來發展,包括動畫,按鈕,連接管理,數據表,JSON,菜單和更多。 旨在發展在世界上最大的字謎遊戲。 用戶可以播放並添加自己的問題。 這是一個填字遊戲和拼字的混合物“。 退房的遊戲 ;務必登錄,然後使用在屏幕底部的菜單,以增加自己的問題。 - DevX,“雅虎豐富的Java開發的Web用戶界面”, DevX有銳感興趣的Java開發一個新的文章 。 納拉亞南的AR寫道:“ 這是第一篇文章由三部分組成的系列,主要針對Java開發,誰不JavaScript的專家,但正在開發Web應用程序與服務器端框架(如JavaServer Pages,Struts或Spring)。 本批中,JavaScript的新手會看到如何使用YUI的設置和設計,並應了解有關面向對象的JavaScript編程的好。 對於開發商已經在JavaScript專家,本系列文章提供YUI庫的介紹。“
- 視頻:“YUI的控制狂”與基督教海爾曼才算是Ajax隊有基督教海爾曼的YUI的視頻交談; 這裡檢查出來或在下面的嵌入播放器。
-
YUI的自動完成和土耳其航空公司網站 : Cagatay Civici 日曆 中寫道告訴我們,土耳其航空公司網站的使用 YUI的自動完成和日曆上的預訂工具。 多年來,許多旅遊網站使用這個組合; Southwest.com是首次採用的YUI日曆之一,並繼續使用原版本的日曆之一,其目前的預訂網站雅虎自己的旅遊網站是一個很好的例子。這些部件可以一起使用-這是實施YUI ImageLoader作者馬特Mlinac。 ( 原始來源。 ) - caridy帕蒂諾Mayea:“YUI3:按鍵控制活動(的keyup的KeyDown,按鍵)” :Caridy(作者的流行起泡圖書館擴展了YUI) 一個新的博客張貼處理3 YUI的關鍵事件 。 ( 原始來源。 )
- YUI組件 : balsamiq樣機,樣機去博客有幾個YUI組件嘲笑使用Balsamiq接口,包括菜單和按鈕 , 日曆 ,和傳送帶 。 ( 原始來源。 )
- 從馬特銳EXT-MVC的斯奈德 : 馬特一直繼續他的銳EXT-MVC項目的工作 。 據馬特,“使用控制器類的AJAX系統的好處是,它簡化了YUI的連接管理和開發人員可以預先註冊的回調,以確保預期的響應類型。 它是在現有http://code.google.com/p/yui-ext-mvc/source/browse/trunk/assets/js/mvc/lib/controller.js 。 在未來,我將增加從服務器獲取JSON和HTML數據的命令模式的邏輯。“
-
保羅Tarjan的地理資源管理器與YQL的和YUI :的 SearchMonkey工程師保羅Tarjan有一個有趣的演示起來使用YUI TabView和雅虎地圖AJAX API顯示一個YQL的地理搜索結果 。 該接口允許你輸入一個地名,然後搜索該位置,該位置的兄弟姐妹,該位置的祖先,等有關的大背景下,為什麼這很有趣, 看到PHP發明者拉斯穆斯Lerdorff的博客文章,關於這個問題的 。 ( 原始來源。 ) - 梅格Smitley - “動態載入YUI的依賴” : 梅格寫(Meglog) :“我一直在使用YUI自去年年底以來,我的應用程序接口的骨幹電網和LayoutManager的 。 它是一個陡峭的學習曲線,我仍然認為自己非常新手,的確,只注意到這個星期的“動態加載”選項卡上的YUI的配置 。 而不是靜態的,包括所需的YUI CSS和JavaScript資源,它有可能使用YUILoader動態負載導入。 雖然我明白,銳,專家將不被我YUILoader-頓悟留下深刻的印象,這種方法幫助我下我的應用程序的的JS文件瘦下來,同時減少維修關注和所以我覺得是值得其他noobs利益提。“ 退房她的文章更多細節 。
- 使用SugarCRM的傳送帶 :羅傑·史密斯在SugarCRM的開發人員的博客教程提供一個快速和簡單的ListView的定制,利用傳送帶部件從雅虎的UI(YUI)庫 。 這種定制完全改變聯繫的ListView的外觀和感覺“行和列”鑑於您的搜索結果雅虎UI傳送帶認為。 YUI庫包含在SugarCRM和提供超出了我們的核心應用使用一噸的UI功能。“
共享和擴展: 書籤del.icio.us Digg它! | reddit!
georgiann帕克特:銳/雅特項目經理(AdaLovelaceDay09)
2009年3月24日,8:06上午由埃里克·米拉利亞| 開發 | 1評論
[ 注:這篇文章是YUI團隊的參與Ada Lovelace的一天 ,慶祝世界 各地的女技師。]
georgiann帕克特(更好地為“喬治”)作為YUI和附屬工程(包括雅特庫)的項目經理。 複雜的技術方案,包括多個項目的計劃管理是最苛刻的工作,在一家軟件公司之一,喬治非常適合挑戰。 她的表帶來快速的智慧,耐心和紀律來管理大量的數據流,一個成功的軟件程序是持續的過程中根深蒂固的理解。 她的背景提供在這裡 - 作為一個C / C + +工程老將,她可以直接與工程師的經驗與她的作品的人同情。
銳發布出去數百個變化,其中有許多是由世界各地的開發建議或貢獻。 自從兩年前加盟球隊,喬治已經徹底改變了所有這些信息的處理方式。 這導致更好的預測,更好的溝通,更好地一刀切質量。
喬治還提供了值得稱道的領導,支持雅虎的主要內部項目的YUI團隊。 當我們指定一個內部項目,作為一個“大賭注”,公司未來的關鍵的東西,我們的團隊項目的前端工程團隊,並確保我們正在竭盡所能,支持他們。 喬治管理這些關係,確保我們的合作者得到及時,構建良好的記錄和其優先次序是準確地反映在我們的發布計劃。 有能力了解不同項目的需求和,faciliate我們的成功合作,是個不小的挑戰,和喬治已經完成繁重的需要,以確保YUI和雅特工程師是整個雅虎在合適的時間提供正確的支持。
說到凍脹解除...... 喬治眾所周知雅虎作為一個出色的技術和YUI的一個不知疲倦的倡導者,但她也是眾所周知的,那些頻繁雅虎的僱員健身房。 你會發現喬治有四,五晚一個星期的工作,能更好地她自己保持的世界紀錄形式的自由權。
喬治的工作和她一般追求卓越的承諾有一定的啟發誰與她的工作在過去的幾年,我們的所有。 我問喬治曾啟發她,送她走向職業生涯技術路徑。
什麼是您使用電腦的第一次經歷?
我是在大學進入前MED軌道的意圖和畢業那年,我作為一個AP微積分課程的大學預科課程的一部分。 幸運的是,老師有兩個蘋果電腦作為一個試驗,在高中階段教編程的一部分贈款。 我們不僅沒有得到它-我們得到了它試圖用最少的代碼做的最強大的功能上具有競爭力。 在大學的第一個數字電子技術課程,在那裡我得到線路板使用彙編語言程序電路密封處理。
你有任何女技師的榜樣,影響了你嗎?
我曾與我留下了深刻的印象,並學到了很多東西從有兩個婦女。 板球軟件的創始人之一,darragh馬爾登,聘請我走出大學校門,成為迄今為止最驚人的啟動我的職業生涯冒險。 她不每SE技師,但我學到了很多,從她的她的人際交往能力方面領先的技術鄉親,建設隊伍,而且越來越多的公司。 其他的女人,我期待和教訓是希拉·布雷迪,在蘋果的系統軟件部門的總監級晉升。 她肯定知道如何推動釋放,在許多情況下,導致大部分男性工程師組成的團隊。 她表現出的信心水平,能力,和侵略性,可以通過任何工程師讚賞-男性或女性 。
共享和擴展: 書籤del.icio.us Digg它! | reddit!
珍妮韓唐納利:YUI的工程師(AdaLovelaceDay09名)
2009年3月24日,8:05上午由埃里克·米拉利亞| 開發 | 3評論
[ Note: This post is part of the YUI team's participation in Ada Lovelace Day , a celebration of female technologists around the world.]
Jenny Han Donnelly is the author of three YUI components:
- The DataTable Control : YUI's DataTable is one of our signature UI widgets, providing a powerful menu of interactive options for tabular data.
- The AutoComplete Control : AutoComplete provides typeahead, suggest, filtration and combo-box functionality to any text input area.
- The DataSource Utility : Shared by DataTable, AutoComplete and the Charts Control , DataSource serves as a conduit between widgets and potential sources of data — including server-side data, JavaScript arrays, and DOM structures like HTML tables.
Jenny's work inspires us in part because of the technical challenges she takes on — try getting fixed headers with xy scrolling to work in IE6 using a semantically sound base table sometime, if you have any doubts. Jenny has taken on some of the most complex HCI challenges anywhere in YUI and engineered them to suit virtually any environment. DataSource enables other YUI components to work with anything from flat files to JSON and XML to JavaScript arrays and DOM structures. We've heard from thousands of people on the YUI forums using all of these features and more in ecclectic and novel ways.
We're also inspired by the organizational leadership Jenny has shown in her time at Yahoo. Currently, she's the lead editor of YUIBlog, bringing technical voices from throughout Yahoo to these pages to share their insights. She has also organized our annual frontend engineering summit at Yahoo, bringing hundreds of Yahoo engineers from around the world together in a rich weeklong technical conference. She's taught weeklong YUI courses to engineers in the USA, Korea and Japan, and she's been an integral member of the hack day group at Yahoo that's such an important part of our engineering culture.
Whether she's coding, writing, teaching or leading — all of which are aspects of the modern technologist's job description — Jenny sets a high bar with her intelligence, dedication, imagination and wit. Ada would be proud.
[ photo of Jenny used by kind permission of Stephen Woods ]
共享和擴展: 書籤del.icio.us Digg它! | reddit!
Survey: When is an Accordion not an Accordion?
March 23, 2009 at 9:20 pm by Christian Crumlish | In Design , Development | 6 Comments
I'm looking for feedback from people who have designed or built an interface using an “accordion” module (or are considering doing so). You see, I've been working on a design pattern for accordion modules, and I'd like to throw out a handful of open questions to the community via this brief survey . I'll be listening elsewhere as well, on twitter ( @mediajunkie ) and on mailing lists where web designers and developers hang out.
(I realize this is not a scientific survey. I'm just interested in engaging the wider community in a discussion instead of trying to impose my view or Yahoo!'s view on the community as authoritative.)
Everywhere I go lately, it seems that interaction designers and web developers are talking about accordion widgets and debating about what makes an accordion an accordion. Not everyone working in this field has heard the term (some may simply refer to “stacked panels” or “collapsible panels”) but most get the gist fairly easily. Ironically, none of the UI elements described as accordions share the actual behavior of a real-world accordion (the musical instrument): namely, that stretching an accordion opens all the folds evenly.
Accordions have been an on-and-off topic of discussion on the main IxDA mailing list ; we discussed them in our Pattern Library workshop in Vancouver earlier this month, and there's been an ongoing discussion about accordions on our internal designer mailing list here at Yahoo!.
So I sat down with some folks from the YUI team (and Marco, the maker of an experimental YUI accordion widget ) a little while ago to sort through a draft of an accordion pattern that might help inform the development of an official YUI component.
Broadly speaking, most people agree on what we're talking about when we talk about an accordion interface element. Everyone agrees that accordions are used to compress content into a limited space and that they consist of panels that can collapse or expand. Beyond this, there are a number of subtle nuances that not everyone agrees on.
One trend I've noticed is that front-end developers tend be agnostic about how the accordion should work, viewing it as really just a variant on a tree widget. Designers tend to be more prescriptive, saying that to be an accordion it must behave in thus and such a way (but not all designers agree on what these rules are).
In the end, the YUI folks will produce code that can be made to do just about anything. We aren't going to try to impose our own taste or preferences in design through the functionality of the code itself. However, we will use the associated pattern to make suggestions and recommendations drawn from the experience of the entire design community, and we will probably lobby for default behaviors that match what most people expect.
So, if you've got a few minutes and an opinion, please visit the survey and let me know what you think!
I'll close the survey on April 30.
共享和擴展: 書籤del.icio.us Digg它! | reddit!

Copyright © 2006-2012 Yahoo! Inc. All rights reserved. Privacy Policy - Terms of Service
支持WordPress的關於雅虎 虛擬主機 。




