建物のサイドライン：YUI + Adobe AIRのレッスン

中| 9時52分に2009年3月31日にはチャド蛍によって午前の開発 、 YUIの実装 | 13コメント

著者について： チャド蛍は、Yahoo!バズ·マーケティング·チームと協力してフロントエンドエンジニアです。 長い間、オープンソースの貢献者、彼は最近開始しましたMiaCMSプロジェクト 、YUIを使って構築されたマンボの次世代のフォーク。 この記事では、彼は、Adobe AIRプラットフォーム上でYUIを使用したデスクトップアプリケーションの開発プロセスを通じて私たちを説明します。

サイドラインのスクリーンショット

これまで何人があなたの会社、ブランド、サービス、製品などについて今言っているのだろうか？ 副業ヤフーの最近の内部のハッキングプロジェクトに触発さが、あなたは人々にリアルタイムで聞かせするための標準的な顧客調査のプロセスを超えて製品の話してから、サービスを強化したり、自分の問題でユーザーを助けるためにそのフィードバックを使用しています。

簡潔に述べたように、我々のプロジェクトの目標はあった

  • 作成、グループ化、およびTwitterに対する高度な検索クエリの自動実行を可能にするデスクトップアプリケーションを作成する
  • 活用し、既存のスキルセットやツール
  • Windows、Mac OS X、およびLinuxオペレーティングシステムをターゲットと記述する必要があり、プラットフォーム固有のコードの量を最小限に抑える
  • 他の人から学ぶことができるようにオープンソースのコードは、に貢献する、および/またはそれらが合うように製品を拡張

フロントエンドエンジニアの我々のチームは、JavaScript、CSS、HTML、およびPHPの専門家ですが、デスクトップ·アプリケーションを開発する豊富な経験を持っていませんでした。 そう質問は、デスクトップ開発のための当社の既存のスキルセットを最大限にする方法については、なった？ 私たちの答えは、利用することであったAdobe AIRプラットフォーム "開発者は複数のオペレーティングシステム上のブラウザ外で実行するリッチインターネットアプリケーションを構築するために実績あるWebテクノロジーを使用することができます"。 AIRは、HTML / JavaScriptの開発（FlexとFlashに加えて）をサポートしているので、我々の上に、従来のWeb技術に私たちのアプリケーションを構築することができましたYUI 、それは3つの主要なデスクトップオペレーティングシステム上で実行されています。

AIRのYUIグリッド

副業はYUIライブラリの豊富な実装が含まれています。 それがうまくいけば、YUIとAdobe AIRを使って実験に興味を持っている他の開発者のための優れた例として役立つべきである。 アプリケーションのレイアウトを使用して構成されているYUIグリッドをもの使用になります最近追加されたARIAのランドマークの役割を 。 グリッドは、AIR環境では非常によく働き、最小限のコード変更を実装するために開発途中で容易に発生した再設計を行いました。 開発者はJavaScriptライブラリの残りの部分を使用しないことを決定し、代わりに別のフレームワークを選んだ場合でも、単に標準的なブラウザ環境にいるかのように、YUIのグリッドは、AIRアプリケーション用の優れた基盤として機能することができます。

AIRのYUIコンポーネント

グリッドに加えて、サイドにも利用ドム 、 イベント 、 ドラッグ＆ドロップ 、 JSON 、 セレクタ 、 コンテナ 、 ボタン 、 メニュー 、 スライダーと、 TabViewのコンポーネントを示します。 私はすべてのYUIコンポーネントはAIR環境で非常によく行われず、変更を必要としないことを報告して満足しています。 副業はかなりカスタマイズされたデザインのため、YUIコンポーネントのいくつかのカスタマイズされたスキンが必要とされたが、コアの変更を実装します。 ほとんどのAIRアプリケーションは、リッチなデスクトップアプリケーションがそれらに感じている傾向にあります。 カスタマイズのこのレベルでは、 YUIスキニングの記事は開始するのに最適なリファレンスです。

ブラウザを超えて

従来のWeb環境上でのAdobe AIRプラットフォームの主要な機能拡張は、ローカルSQLiteデータベースとユーザのファイルシステムへのアクセスです。 ローカルデータベースへのアクセスは、このような歯車とHTML 5のクライアントサイドのストレージとして技術により従来のWeb環境で多くの利用できるようになっていますが、今のところ、これらのソリューションはユビキタスではありません。 AIRの開発に興味のある方は、サイドラインは、典型的なAIRアプリケーションが必要とする可能性がある一般的なタスクの多くを取り組んできた。例えば、ネイティブのブラウザウィンドウを立ち上げ、ローカルファイルシステムでの作業は、ローカルデータベースとの対話、アプリケーションの更新を処理する、外部データを取得、デスクトップ通知を表示するなど、それはその点で有用な参照であることを証明する必要があります。

AIR開発のためのヒント

  1. お使いの環境を知っています。 AIRは、ボンネットの下にWebKitをオープンソースのブラウザエンジンを使用します。 従来のWeb開発は、できるだけ多くのブラウザ/オペレーティングシステムなどの間でアプリケーションやサイトの作品を作ることを目的としている。 どのブラウザをサポートするためには、通常、コスト対使用率にダウンしています。 ただし、単一のレンダリングエンジンのコーディングは、市場の潜在的な組み合わせの方向転換に対する準備およびテストする必要がなくなります。 アプリケーションは、より伝統的なブラウザ環境に戻す方法を見つける必要がある時が来るかもしれないので、言われていること、それはまだ可能であれば、クロスブラウザな方法で開発することは理にかなっています。 YUIのようなフレームワークを使用すると、そのプロセスは比較的簡単になります。 これは、現在を経由してYUIでサポートされているブラウザとプラットフォームを確認することは簡単である傾斜ブラウザのサポートグラフを 。 開発者はAIRアプリケーションを（使って構築するときにいくつかの基本的なショートカットを取ることはかなり安全なはず-webkit-border-radius角の丸い風になります）、しかし控えめにそれらを使用し、彼らは後で見つけやすいように、それらを文書化します。
  2. どのような環境で複雑なアプリケーションの開発中にデバッグ·ツールの固体セットは、持っている必要があります。 アドビでは、ボックスから空気をデバッグするためのいくつかの便利なツールを提供します。 開発者は、調査する必要がありますがAIR Debug Launcher（ADL） 、 HTML Introspectorのと、 HTMLソースビューアを 。 バンドルされたツールに加えて、 そのAdobe AIRのプラグインを使用したAptanaのStudioは、必要不可欠な資産であることが判明した。 Aptanaのプラグインは、AIRプロジェクトの作成、一般的なJavaScriptフレームワークのインポート、デバッグ、パッケージング/エクスポート、およびデジタルアプリケーションに署名と支援を提供しています。
  3. （すなわち、あなたのイメージを最適化するアプリケーションのCSSやJavaScriptファイルを縮小すると結合し、副業のような重いイベントベースのアプリケーションのための利点を活かすことが我々は標準的なブラウザ環境から学んできたパフォーマンス技術を忘れてはいけないイベント委譲のテクニック ） 。 AIRアプリケーションは、デスクトップ上で実行するので、そこに典型的なブラウザ環境では、よりパフォーマンスをもう少し寛大であるが、単にブラウザ自体のように覚えて、AIRのコンテナは、アプリケーションのカスタムコードが作動する前でも、システムのメモリのチャンクを消費。

前方の道路

サイドラインのベータバージョンは、インストールすることができますhttp://sideline.yahoo.com 。 コードはBSDライセンスの条件の下でオープンソースとGitHubでホストされている 。 我々は貢献、フィードバック、および/または提案を歓迎します。 また、可能な限りオープンなものを維持し、新技術をサポートしているの精神で、我々は、おそらくにサイドラインを移植するチタン 、近い将来に。 いくつかの初期作業は、すでにポート上で行われており、今後数週間にわたって継続されます。 それは副業のようなJavaScriptのORM実装してしまうということも非常に可能性がありJazzRecordプラットフォーム間でデータベースの相互作用を容易にするためです。 誰もが複数のプラットフォームをサポートするための追加のヒントを持っている場合、我々は彼らを聞いてみたい。

今すぐ出て行くと、それをフォーク ！

会話を検索： Bloglinesの | テクノラティ

共有および拡張： del.icio.usでブックマーク | Diggそれ！ | reddit！

インプリメンテーション·フォーカス：DocLanding

10:24 2009年3月30日には、Eric Miragliaによって午前|でYUIの実装 | 1件のコメント

DocLanding：オンライン、オンデマンド文書管理

トッドFishbackの社長であるDocLanding 、Webベースの文書管理ソリューションを提供します。 トッドはDocLandingユーザーインターフェイス内でYUIユーティリティとウィジェットの彼のチームの選択肢を議論するためにYUIBlogに参加していただきます。 あなたからDocLandingについて詳しく学ぶことができます2008年秋のDEMOカンファレンスでのプレゼンテーション 。

私たちDocLandingについて少し教えて-あなたのユーザーのために解決する中心的な問題は何ですか？

DocLandingは、ほとんどのエンタープライズ·ソリューションのコストのほんの一部のためにエンタープライズクラスのドキュメント管理機能を提供するオンデマンドドキュメント管理ソリューションです。 ソフトウェアはサービス（SaaS）を提供するとして、または社内のシステムとして当社のソフトウェアを介して配信することができます。 当社のクライアントは、金融サービスや医療アリーナで、主である。

我々は顧客のために解決する一般的な問題は、分散労働力のためのWebベースの集中リポジトリを提供する低紙ボリュームオフィス向けのオンデマンドWebベースのスキャン、および高い紙のボリュームオフィスのデスクトップバッチベースのスキャンが含まれます。 他の問題は我々のアドレスは、電子透かしの安全な文書共有とコラボレーション、ドキュメントの編集/注釈、バージョン管理、コメント、ドキュメント、およびドキュメントが含まれています。 個別に制御がリンクされたドキュメントリポジトリへの私たちのユニークなアプローチは、ユーザーが一つの共通ログインに分散したリポジトリにアクセスすることができます。

お使いの製品の設計によって提示された特定のユーザー·インターフェースの課題は何でしたか？

DocLanding：ドキュメントのプレビューUI。

我々はあなたが単にユーザーフレンドリーなデザインの重要性を過小評価することはできません私たちの以前の仕事の一部から学びました。 ウェブサイトを作成することはかなり簡単ですが、ビジネスマンのニーズを満たすために持って真のWebアプリケーションを作成すると、実際の作業です。 当社の製品は、大企業の厳密なドメインからの文書管理を取ると、任意の中小企業が利用できるようにしようとします。 そのコアで電子文書管理は簡単な作業ではありません。 目標は、彼らが完全に検索することに加えて整理すると、ファイルの大規模な番号へのアクセスを制御することです。 私たちの開発時間の大半は伝統的に費やされている場合は、このため、ユーザー·インターフェースは、実際には。

私達はあなたのサイトが簡単で使いやすくするときに、サポートの問題に時間とお金を節約することがわかりました。 の一部はサイトを実行するために必要な仕様をリラックスされています。 我々は我々には、JavaScriptとFlashを使用してちょうど約あらゆる現代的なブラウザにまで縮小しました。 我々が思いついたコアサイトのデザインは、画面の不動産は、非常に具体的な使用で独自の課題を提示した。 我々は、ユーザーが我々自身が色、図像とその機能へのコントロールの近接性に着目したときに、アプリケーションを最大限に活用した方が良いことができたが見つかりました。 我々は、フィードバックページがヘルプの要求に比べ、追加機能のために多くのリクエストが返されましたので、我々は正しい軌道に乗っていると思います。

あなたのサイトパワーを助けるためにYUIを選んだ。 何がその決定に導く？

DocLanding：文書管理オンデマンド

簡単な答えは一貫性とスピードです。 私達は私達が私達のプロダクトの設計仕様を満たすために可能になるフレームワークを必要としていました。 具体的には、1画面表示を維持し、フルページポストバックを最小化または排除するような野心的な設計目標を持っていた。 さらに、我々が管理できるようになり、できるだけ多くの異なるブラウザで同じように機能するために私たちの必要な要素を求めていました。 既にと競合するブラウザとそのレンダリング手法の間に十分な一貫性の問題がありますので、ブラウザ固有の我々がしなければならないでしょうコーディングの量を最小限にするために必要な我々が選んだ任意のフレームワーク。 別のツールキットの様々な実験をした後、YUIは上に非常にはっきりと出てきた。 そこにすべての製品に学習曲線のビットがあったが、YUIの最高のペイオフがありました。

ベースのフレームワークはプラグインを必要としない、それは。NETとよく果たしており、スクリプトは、光タイトでしっかりしている。 かつて我々はフレームワークのハングを持って、我々はそれがYUIのバージョンに私たちの古い伝統的なインタフェースのページを比較するために啓発た。 すべてのケースで、我々のUI手法を調整すると、お客様に軽くダウンロードのパフォーマンスと一貫性の巨大な利益を返していました。

DocLanding：YUIのアップローダを使用して複数ファイルのアップロード。

あなたのアプリケーションで最も頻繁に何YUIコンポーネントを使用していますか？

我々は、実際のコンポーネントのかなり多くを使用しています。 最も有益なものは、私たちは可能な限り1画面で、オンと同じくらい操作を行うことができているものされているので、 TreeViewコントロール 、 メニュー 、 SimpleDialogとレイアウトマネージャは、非常に有用であった。 真実では、ほぼすべてのコントロールを使用しているが、我々は特に感謝アップロードコントロールに複数のファイル選択を処理するための能力を。 我々はしばらくの間その問題に対する解決策を探していたとYUIのは、我々がこれまで遭遇した中で最もエレガントされています。 我々はうまく利用してJSONユーティリティとの接続マネージャを大幅に私たちのフットプリントを抑え、さらに重要なことに待機していない、働く我々のユーザーを保持して我々が作る、サーバーへの要求のサイズと数を最小限に抑えるためです。

DocLandingのために次は何ですか？ あなたは今後のリリースで対処するために取り組んでいる課題は何ですか？

我々は常に我々の製品の機能セットを改善するために取り組んでいます。 私たちのユーザーは、我々はそのための時間を作ってあげるように優れたメインアプリケーションとそのドキュメントの編集を統合する機能を求めている。 我々はまた、優れた大容量ファイルのアップロードに対応に取り組んでいます。 さもなければ、私達はテーブルの上にいくつかのアイデアを持って、私たちはものが私たちのユーザーにとって最も有益であろうその計量ています。 携帯電話やネットブック用に最適化サイトのバージョンがDocLandingに直接デスクトップから構造化されたフォルダをインポートするためのツールと​​してだけでなく、すでに設計段階にあります。 実験的に、我々は唯一のウェブサイトでメタデータを格納すると我々のソフトウェアを稼動しているネットワーク上のクライアントマシンから直接コンテンツを引っ張ってのアイデアをいじるています。 最終的に、我々のユーザーのニーズは、我々が次の移動どのような方向で決まります。

会話を検索： Bloglinesの | テクノラティ

共有および拡張： del.icio.usでブックマーク | Diggそれ！ | reddit！

YUIオートコンプリートでFlickrのファーストピープルファインダーを構築する

8時59分に2009年3月26日はロスHarmesによって午前|中開発 | 1件のコメント

でFlickrの 、我々は最近、私達のページのいくつかに新しい人セレクタウィジェットを追加し、この機能は基づいていますYUIオートコンプリートコントロール 。 人セレクタウィジェットが私たちのメンバーは、20,000エントリの上方を含めることができ、その連絡先リストから個人を選択することができます。 関係する大量のデータのために、データをフェッチし、解析するための伝統的な技法は、非常に解析時間を遅らせることにより、主に、現実的ではありませんでした。 この記事では、我々がしようとしたオートコンプリートの設定で、我々は、最もパフォーマンスであることが判明し、異なるデータフォーマットの一部を見てみましょう。

まず、ここでは、我々が達成しようとしていたもののビデオの要約です。人々ファインダーウィジェットの新しい相互作用は、右側に描かれています。

フェッチと解析：XHRおよびカスタムのデータ

セキュリティで保護された - 何よりも - 最大の課題は、ダウンロードする高速解析するために、高速になるデータ形式を見つけることだった。 まず、XMLとAjaxを試みたが、XML構文解析は遅いがはるかにであることが証明さ - 実際には、我々はこのアプローチは、大きなデータセット上でブラウザをダウンさせることがわかった。 次に我々は、JSONとAjaxの組み合わせを試してみましたが、これはかなり速かったが、それはまだ私たちの最大のデータ·セット（配列はおおよそ10700オブジェクトは、いくつかのプロパティを持つそれぞれを含む）を解析するために80以上の秒かかりました。

最後に、我々は非常に速いことが判明した2トランスポート/解析技術を見つけました。

  1. 動的に生成されたスクリプトタグを使用してJSONを（コールバック関数内にラップ）の取得。
  2. 使用してカスタムデータ形式（制御文字で区切られたリスト）の解析split()は、Ajax（使用してフェッチされたYUI Connection Managerを ）。

最後に、我々は、カスタムの形式で行ってきました。 それは動的なscriptタグによって実行されることができるように私たちのJSONをフォーマットすると、安全性の低いアプローチではなく、パフォーマンスの勝利だった。 XHRを使用すると、私たちに、より安全で、まだ非常にパフォーマンスの高いソリューションを与えた。

ユーザーとの対話：YUIオートコンプリート

かつて我々はすぐにJavaScriptにデータを取得する方法があったが、次の課題は、ユーザーが迅速に連絡先のリストを検索するための方法を作成することでした。 これを達成するために、我々は、YUIのAutoCompleteコントロールになった。 それはまさに我々のニーズを満たす： 非常に速く、非常に構成可能。 私たちのカスタムデータを使用して、それを使用するために、我々はオートコンプリートのインスタンスのDataSourceとして使用する関数を作成し、ウィジェット内のすべてのキー入力は、この関数をトリガし、検索文字列を渡します。 この関数内で、我々は、メンバーのすべての連絡先をループ処理し、4つの異なるフィールドのクエリに一致するようにしてください。 我々は、文字列照合を行うために正規表現を使用していました。

でも、連絡先の大規模なセットのために、我々はこの手法は非常に効率的であることがわかった。 ここで我々が​​やったことの基本的なバージョンは、次のとおりです。 

 機能searchContacts（クエリ）{

        VARマッチ= []、
            queryRegEx =新しいRegExpオブジェクト（クエリ、 'I'）、/ /クエリがなければなりません
                                                 / /前にチェック 
                                                 / /正規表現で使用します。
           お問い合わせ。

         {（; N <lenはN + + VAR n = 0の場合、len = contacts.length）の

               コンタクト=連絡先[N];

                IF（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ミリ秒です）。 これは、キーを押すと開始された検索の間に遅延がないことを意味します。 そこに、この（あなたが立て続けに数文字を入力した場合、オートコンプリートの表示が少しちらつきする傾向がある）に欠点がありますが、我々はそれが我々が作った最大の単一の改善、さらにGoogleの検索機能に最適化よりも重要であることがわかった。 一方queryDelay 200msの以上のは、XHRや他のリモートデータソースの方が適切かもしれませんが、我々は、正規表現ベースのローカルデータを使用してDataSourceのことがわかったすべてのキーストロークで検索の課題を克服しました。 オートコンプリートでは、我々は、任意の検索が一度だけ行われなければならないようにミックスに追加されたフリーキャッシ​​ュを得ました。

異なるデータフォーマットに関する完全な詳細と、それぞれのための広範なプロファイリングデータを含むこれらの技術のすべての詳細については、に記載されていますcode.flickrのブログ。

会話を検索： Bloglinesの | テクノラティ

共有および拡張： del.icio.usでブックマーク | Diggそれ！ | reddit！

2009年3月25日のために野生の

中|午前9時08分に2009年3月25日は、YUIチームが午前ワイルドで | 3コメント

過去数週間のうちにYUIのコミュニティからのニュースやメモ。 私たちが逃した何コメント欄で知らせてほしい、と我々は、次回が得られます。

会話を検索： Bloglinesの | テクノラティ

共有および拡張： del.icio.usでブックマーク | Diggそれ！ | reddit！

Georgiann Puckett：YUI / ASTRAプログラムマネージャ（AdaLovelaceDay09）

午前8時06分に2009年3月24日には、Eric Miragliaによって午前|中開発 | 1件のコメント

DAVガラスとYUIチームのジョージPuckett

[ 注：この記事はのYUIチームの参加の一環であるエイダラブレースデーは、世界中の女性技術者の祭典。]

Georgiann Puckettは（優れている "ジョージ"として知られている）YUIと関連プロジェクト（ASTRAライブラリを含む）のプログラムマネージャとしての役割を果たします。 複数のプロジェクトを含む複雑な技術的プログラムのプログラム管理は、ソフトウェア会社の中で最も過酷な仕事の一つであり、ジョージは、理想的な課題に適しています。 彼女はテーブルに迅速にインテリジェンス、大量のデータストリームを管理するための忍耐と規律、そして成功したソフトウェアプログラムが維持されることにより、プロセスの深く根ざした理解をもたらします。 彼女の背景がここにも役立つ - C / C + +エンジニアのベテランとして、彼女は働く人のエンジニアの経験と直接共感することができます。

YUIのリリースでは変更が数百、そのうちの多くは、世界中の開発者によって提案された、または貢献していて出て行く。 二年前にチームに入社して以来、ジョージはそのすべての情報が処理される方法に革命をもたらしました。 それは、より良い予測を、より良いコミュニケーション、ボード全体の品質向上につながっている。

ジョージはまた、Yahooの主要な内部プロジェクトを支援するYUIチームのために立派なリーダーシップを提供しています。 我々は "大きな賭け"と、同社の将来にとって重要なものとして内部プロジェクトを指定するとき、我々はプロジェクトのフロントエンド·エンジニアリング·チームとチームアップし、我々は彼らをサポートするために、我々ができることはすべてをやっていることを確認してください。 ジョージは私たちの共同研究者が適時、適切に文書化されたビルドを取得し、その優先順位が正確に私たちのリリース計画に反映されていることを確認し、これらの関係を管理します。 多様なプロジェクトのニーズを理解し、我々の成功したコラボレーションを容易にするために能力を持つことは決して小さな課題ではない、とジョージは、YUIとASTRAのエンジニアは、Yahoo全体の適切なタイミングで適切なサポートを提供していることを確認するために必要な力仕事をしました。

物を持ち上げるヒービングといえば.... ジョージはよくYUIのために卓越した技術者と精力的な提唱者としてヤフーに知られているが、彼女はまた、よく人が頻繁にYahooの従業員のジムに知られているんされています。 あなたはそこにジョージ4または5泊フリーウェイトに彼女自身の世界記録フォームをより良くするために働く週を見つけることができます。

ジョージの仕事と卓越性への彼女の一般的なコミットメントは、確かに過去数年にわたって彼女と一緒に働く人たちすべてに影響を与えています。 私は彼女にインスピレーションを与え、技術のキャリアへの道を彼女を送った人ジョージに尋ねた。

コンピュータとの最初の経験は何でしたか？

私は大学で事前-MEDのトラックを入力すると上の意図だったと私は大学の予備校のカリキュラムの一環として、私年生のAP微積分のコースを持っていた。 運にそれがあるので、教師は、高校レベルでのプログラミングを教えるために試験の一部として2つのアップルコンピュータのための助成金を得た。 だけでなく、我々はそれを手に入れた-我々はそれがコードの最低額で最も強力な機能を実行しようとしてで競争ました。 私はアセンブリ言語を使用して、ブレッドボード上でプログラム回路になった大学内の最初のデジタル電子機器コースは契約を封印した。

あなたが影響を受けた女性技術者の役割モデルを持っていましたか？

私は私が感銘を受けてから多くを学ばれたことで働いてきた二人の女性があります。 Darraghマルドゥーン、クリケットソフトウェアの共同創設者、私のキャリアの中で最も素晴らしい起動冒険はるかに大学から私を雇った。 彼女はそれ自体が技術者ではなかったが、私はチームを構築し、会社を成長させる、主要な技術的な人々に彼女の人々のスキルを基準にして彼女から多くのことを学びました。 私はルックアップしてから学んだ他の女性は、Appleのシステムソフトウェア部門でディレクターレベルに階段を上がったシーラブレイディでした。 彼女は間違いなく男性エンジニアのほとんどが構成されるチームをリードする多くのケースでは、リリースを駆動する方法を知っていた。 男性または女性-彼女は信頼性のレベル、能力、およびすべてのエンジニアに理解されることが攻撃性を示した 。

会話を検索： Bloglinesの | テクノラティ

共有および拡張： del.icio.usでブックマーク | Diggそれ！ | reddit！

ジェニーハンドネリー：YUIエンジニア（AdaLovelaceDay09）

中| 8時05分に2009年3月24日には、Eric Miragliaによって午前開発 | 3コメント

ジェニーハンドネリー、シニアエンジニア、ヤフー、YUIのDataTableの作成者は、DataSourceとオートコンプリート

[ 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:

  1. The DataTable Control : YUI's DataTable is one of our signature UI widgets, providing a powerful menu of interactive options for tabular data.
  2. The AutoComplete Control : AutoComplete provides typeahead, suggest, filtration and combo-box functionality to any text input area.
  3. 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 ]

会話を検索： Bloglinesの | テクノラティ

共有および拡張： 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

example of an accordion 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.

会話を検索： Bloglinesの | テクノラティ

共有および拡張： del.icio.usでブックマーク | Diggそれ！ | reddit！

次のページ»
ヤフーが主催する

著作権©2006-2012ヤフー株式会社すべての権利を保有。 プライバシーポリシー - サービス利用規約

を搭載ワードプレスでヤフー ウェブホスティング 。