Сграда странична: Уроци по Юи + Adobe AIR

31 март, 2009 в 9:52 ч. от Чад Auld | в развитието , Юи реализации | 13 Коментари

За автора: Чад Auld е предния край инженер, който работи с екипа на Yahoo! Buzz Маркетинг. Дълго време с отворен код сътрудник, наскоро той ми помогна да започна проект MiaCMS , следващото поколение на разклонението на Mambo, построени с помощта на Юи. В тази статия, той ни върви през процеса на разработване на десктоп приложение на Юи върху платформата на Adobe Air.

Снимка на странична

Винаги се чудя какво казват хората точно сега за Вашата фирма, марка, услуга, продукт, и т.н.? странична , вдъхновена от скорошно вътрешен проект за хак на Yahoo!, излиза извън рамките на стандартния процес за проучване на клиента, за да ви позволи да слушате в реално време с хората говорим за вашите продукти и след това да използвате тази обратна връзка, за да разшири възможностите ви за услуга или да помогне на потребителите с техните проблеми.

Накратко казано, целите на нашия проект са

  • Създаване на десктоп приложение, което позволява създаването, групиране, и автоматично изпълнение на съвременни заявки за търсене в Twitter
  • Осигуряване на съществуващите умения и комплекти от инструменти
  • Насочете Windows, Mac OS X и Linux операционни системи и минимизиране на размера на платформа специфичен код, който трябва да бъдат написани
  • Отвореният код на код, така че другите да се учат от, да допринесе, и / или разширяване на продукта, както намерят за добре

Нашият екип от предния край инженери са експерти в JavaScript, CSS, HTML и PHP, но не са имали много опит в разработването на десктоп приложения. Така че въпросът стана, как да се максимизират нашите съществуващи умения-комплекти за настолни развитие? Отговорът за нас беше да се използва Adobe AIR платформа , която "позволява на разработчиците да използват доказани уеб технологии, за изграждане на богати интернет приложения, които работят извън браузъра на няколко операционни системи". Тъй като AIR поддържа HTML / JavaScript развитие (в допълнение към Flex и Flash), бихме могли да изградим прилагане на традиционните уеб технологии, на върха на Юи , и го стартирате в трите основни операционни системи за настолни.

Юи Grids във въздуха

Странична съдържа обширна изпълнение на библиотеката на Юи. Тя трябва да се надяваме да послужи като добър пример за други разработчици, които искат да експериментират с Юи и Adobe AIR. Прилагането на оформление се строи с помощта на Юи Grids и дори се възползва от наскоро добавени ARIA забележителност Роли . Grids работи много добре в средата на въздуха и Редизайн, които са се появили в средата на развитие, лесен за изпълнение с минимални промени код. Точно както в стандартната среда на браузъра, Юи Grids може да послужи като добра основа за AIR приложение, дори ако разработчикът реши срещу използването на останалата част от библиотеката на JavaScript и избра друга рамка, вместо.

Юи компоненти във въздуха

В допълнение към Grids, странична също използва Дом , събитие , плъзгане и пускане , JSON , избора , контейнер , на бутоните , меню , слайдер , и TabView компоненти. Аз съм щастлив да докладва, че всички Юи компоненти се представи изключително добре в средата на въздуха и са необходими никакви промени. Странична прави прилагане на сравнително персонализирани дизайн и по този начин някои потребителски одиране на компонентите на Юи се изисква, но не основни модификации. Повечето приложения на AIR са склонни да имат богато приложение за настолен усещане за тях. За това ниво на персонализация, одиране Юи статия е чудесен източник, за да започнете.

Отвъд браузъра

Основно подобрение на Adobe AIR платформа през уеб традиционната среда е достъп до локалната база данни SQLite и файловата система на потребителя. Локална база данни, достъп става все по-достъпни в традиционните уеб среда чрез технологии, като например Gears и HTML 5 страна на клиента за съхранение, но за сега тези решения не са навсякъде. За тези, които са заинтересовани в развитието на въздуха, странична се е занимавал много на общите задачи, които типично прилагане на въздуха може да се наложи, например, извличане на външни данни, обработка на приложения актуализации, взаимодействие с локална база данни, работа с локалната файлова система, стартира местните прозорци на браузъра, показване на известия на работния плот и т.н. Трябва да се окаже полезна отправка в това отношение.

Съвети за развитие на въздуха

  1. Знай вашата среда. Air използва WebKit браузър с отворен код под предния капак. Традиционните уеб развитие е насочена към заявление или място за работа, намира като много браузъри / операционни системи, като е възможно. Кои браузъри, да подкрепят обикновено се свежда до цена в сравнение с използването на фактор. Въпреки това, кодиране за един двигател за оказване намалява необходимостта да се подготвят за и да се тества срещу обръщам на възможните комбинации в пазара. Това се каза, че все още има смисъл да се разработят в различни браузъри начин, когато е възможно, тъй като може да дойде време, когато заявлението трябва да намери своя път обратно в по-традиционен браузър среда. С помощта на рамка, като Юи ще направи този процес сравнително безболезнено. Тя е проста, за да видите браузъри и платформи, поддържани в момента от Юи чрез сортирани диаграма на браузъра подкрепа . Разработчиците трябва да бъде сравнително безопасно да се вземат някои основни комбинации, при изграждане на въздушна приложение (използване на -webkit-border-radius прави заоблени ъгли бриз), но ги използват пестеливо и ги документира, така че те са лесни за място, по-късно.
  2. По време на разработването на сложни приложения във всяка среда солиден набор от инструменти за отстраняване на грешки е, трябва да имате. Adobe предлага няколко полезни инструменти за отстраняване на грешки на въздух от кутията. Разработчиците трябва да разследва AIR Debug стартера (ADL) , на HTML Introspector , и HTML Viewer източник, . В допълнение към пакет от инструменти, Aptana Studio със своята Plug-in за Adobe AIR се оказа незаменим актив. Плъгин Aptana предоставя помощ със създаването на въздушен проект, вноса на общи рамки на JavaScript, отстраняване на грешки, опаковката / износител, и цифрово подписване на заявлението.
  3. Не забравяйте за изпълнение техники, които сме научили от стандартния браузър на околната среда (т.е., оптимизиране на вашите изображения, стопяват и се комбинират прилагането на CSS и JavaScript файлове, както и за тежки случаи-базирани приложения, като странична, възползвайте се от техники за събития делегиране ) . Въздушни приложения тичам на работния плот и така там е малко повече снизходителност с изпълнението, отколкото на типичен околната среда браузър, но си спомням точно както самия браузър, на AIR контейнер също консумира парче на системна памет, дори преди потребителски ритници на приложението код в .

Пътят напред

Бета версия на странична може да се инсталира по http://sideline.yahoo.com . Кодът е с отворен код под условията на BSD лиценз и хоства на GitHub . Ние приветстваме вноски, обратна връзка, и / или предложения. Също така, в духа на запазване на нещата такива, каквито отворено и да подкрепя нова технология, ние вероятно ще пристанището странична Titanium в близко бъдеще. Някои първоначалната работа вече е било направено на пристанището и ще продължи през следващите седмици. Също така е напълно възможно, че странична ще приключи изпълнението на ORM на JavaScript, като JazzRecord да облекчи база данни взаимодействия между различните платформи. Ако някой има допълнителни съвети за поддръжка на множество платформи, ще се радваме да ги чуе.

Сега излезе и го трапезата !

Споделете и разширяване : Запазете си отметка към del.icio.us | Digg тя | Reddit!

Изпълнение Фокус: DocLanding

30 март 2009 в 10:24 ч. от Ерик Miraglia, | В реализации Юи | 1 Коментар

DocLanding: Online, при поискване за управление на документи

Тод Fishback е президент на DocLanding, уеб-базирано решение за управление на документи. Тод се присъединява към нас върху YUIBlog за да обсъдят възможността за избор на отбора си Юи на комуналните услуги и джаджи в рамките на DocLanding потребителски интерфейс. Можете да научите повече за DocLanding от представянето му на есен 2008 Demo конференция .

Разкажи ни малко за DocLanding - какви са основните проблеми, които решават за вашите потребители?

DocLanding е по заявка решение за управление на документи, която осигурява корпоративен клас функционалност за управление на документи, за една малка част от разходите на повечето корпоративни решения. Софтуерът може да бъде доставен чрез нашия софтуер като услуга (SaaS) предлагане или като вътрешна система. Нашите клиенти са предимно във финансовите услуги и здравни арените.

Общи проблеми Ние решаваме за нашите клиенти включват предоставяне на уеб-базирана централизирано хранилище за разпределени работна ръка, уеб-базирана сканиране по заявка за ниски хартия обем офиси, както и десктоп базиран партида сканиране в високо хартиени обем офиси. Други въпроси ние адрес включват сигурен обмен на документи и сътрудничество, редактиране на документ / анотации, контрол на версията, документ коментира и филиграниране документ. Нашият уникален подход към отделно контрол, но свързани с хранилища на документи позволява на потребителите достъп коренно различни хранилища с един общ вход.

Какви са били конкретно потребителски интерфейс предизвикателства, представен от дизайна на вашия продукт?

DocLanding: Документ UI предварителен преглед.

Ние научихме от някои от по-рано нашата работа, че просто не може да се подценява значението на лесен за употреба дизайн. Създаването на един сайт е сравнително лесно, но създаването на един истински уеб приложение, което трябва да отговарят на нуждите на бизнесмените, е истинска работа. Нашият продукт се опитва да поеме управлението на документ от стриктно домейн на голямо предприятие и го прави достъпен за всеки малък бизнес. Електронно управление на документи в същността си не е проста задача. Целта е да се организират и контролират достъпа до огромния брой файлове, в допълнение към което ги прави напълно търсене. Поради това, потребителският интерфейс е действително където традиционно са похарчени по-голямата част от нашето развитие време.

Ние открихме, че ще спестите време и пари за подпомагане въпроси, когато направите сайта си прост и лесен за използване. Част от това е релаксиращо спецификациите, необходими за да стартирате сайт. Има нашата сравнение до почти всеки съвременен браузър с JavaScript и Flash. Ние излязохме с ядро ​​сайт дизайн, представи своите собствени предизвикателства, с много специфичен използването му на екрана на недвижими имоти. Намерихме нашите потребители са по-добре могат да се възползват в пълна степен на заявлението, когато ние самите обърна внимание на цветове, иконография и близостта на проверките на тяхната функция. Смятаме, че сме на прав път, защото нашата страница за обратна връзка се е върнал повече искания за допълнителни функции, отколкото за помощ искания.

Вие избрахте Юи, за да помогне на вашия сайт. Това, което е довело до това решение?

DocLanding: На заявка за управление на документи

Простият отговор е, последователност и скорост. Имахме нужда от рамка, която ще ни позволи да отговарят на спецификациите за дизайн на нашия продукт. По-конкретно, имахме амбициозни цели за дизайн като поддържането на един екран и да се сведат до минимум или премахване на пълни postbacks страница. В допълнение, ние искахме нашите необходимите елементи, за да изглежда и функционира по идентичен като на много различни браузъри, тъй като ние може да се справи. Има достатъчно въпроси за съгласуваност между браузъри и техните оказване методологии, за да се бори с вече, така че всяка рамка, ние избрахме да се намали размерът на браузъра специфично кодиране ние ще трябва да направите. След като експериментира с разнообразие от различни комплекти с инструменти, Юи излезе съвсем ясно на върха. Имаше малко на кривата на обучение за всички продукти, но Юи имаше най-добрият финал.

Рамката база не изисква щепсел, играе добре. NET, и скриптовете са леки, стегнати и твърди. След като имаме цаката на рамката, открихме, че е поучително да се сравни нашите по-големи традиционни страници интерфейс на версията Юи. Във всеки случай, коригиране UI методология ни връща огромни печалби в производителността и последователност с по-леки сваляния на нашите клиенти.

DocLanding: MULT качване на файлове с използване на Юи Качил.

Какво Юи компоненти се използват най-силно в приложението ти?

Ние всъщност доста от компонентите. Най-полезните от тях са били тези, които позволяват на нас да направим, колкото и на един екран е възможно, така TreeView , Меню , SimpleDialog и Разпределение Мениджър са били изключително полезни. В интерес на истината сме почти всички контроли, но ние особено ценим Качил контрол способността да се справя с множество избор на файл. Ние търсим решение на този проблем за известно време и Юи е най-елегантният ние сме срещали досега. Ние правим добро използване на помощната програма за JSON и мениджър на връзката, за да намали до минимум размера и броя на исканията на сървъра, ние правим, което държи на нашия воден отпечатък и по-важното пази нашите потребители, работи, не чака.

Какво е следващия за DocLanding? Какви са предизвикателствата, с които се работи за справяне в предстоящите издания?

Ние непрекъснато работим за подобряване на набор от функции на нашия продукт. Нашите потребители са поискали да се интегрират по-добре за редактиране на документите им с основното приложение, така че ние ще направим време за това. Ние сме също така работи върху по-доброто включване на големи качвания на файлове. В противен случай, ние имаме няколко идеи на масата и ние сме с тегло, кои от тях би било най-полезно за нашите потребители. Версия на сайта, оптимизирана за мобилни телефони и нетбуци е в етапа на проектиране вече, както и инструменти за внос на структурирани папки от работния плот директно в DocLanding. Експериментално, ние сме си играеше с идеята за само съхранение на метаданните в сайта и издърпване на съдържание директно от мрежови клиентски машини, които управляват нашия софтуер. В крайна сметка, на нуждите на нашите потребители ще диктуват в каква посока се движим следващия.

Споделете и разширяване : Запазете си отметка към del.icio.us | Digg тя | Reddit!

Да изградим бързо народна намиране на Flickr с Юи Автодовършване

26 март, 2009 в 8:59 ч от Рос Harmes, | в развитието | 1 Коментар

Flickr , наскоро добави един милион нови хора селектора джаджа няколко от нашите страници, тази функция се основава на Юи Автодовършване контрол . Джаджа позволява на хората за избор на нашите членове да изберете лица от списъка си с контакти, който може да съдържа повече от 20000 записа. Поради голямото количество данни, включени в традиционни техники за извличане и анализ на данни не е възможно, най-вече поради изключително бавен при разбора пъти. В този пост, ние ще разгледаме някои от най-различни формати на данни, ние се опитахме и в на AutoComplete конфигурация ние установено, че са най-performant.

Първо, ето едно видео рекапитулация на това, което ние се опитваме да постигнем ново взаимодействие с хора, намиране джаджа е изобразен на правото:

Извличането и разбор: XHR и потребителски данни

Най-голямото предизвикателство е намирането формат на данни, които са бързо да изтеглите, бързо да се направи разбор, и - над всичко друго - сигурен. Ние за първи път се опитах XML и Аякс, но разбор на XML се оказа много да се забави - в действителност, ние открихме, че този подход може да донесе на браузъра по-големи масиви от данни. След това се опитах комбинация от JSON и Аякс, това е значително по-бързо, но тя все още се повече от 80 секунди, за да се анализира нашият най-голям набор от данни (масив, съдържащ около 10700 предмети, всеки с няколко свойства).

В края на краищата, ние открихме два транспортни / синтактична техники, които се оказаха изключително бързо:

  1. Извличането JSON (увит в функция за обратно извикване) с динамично генерирани скриптове тагове;
  2. разбор на потребителски формат на данните (контролен характер запетаи списък) с split() , пресилено с Ajax (с помощта на Юи Connection Manager ).

В края на краищата, ние отидохме с потребителски формат. , Форматиране нашата JSON, така че тя може да бъде изпълнен с динамичен таг скрипт е по-малко сигурен подход, а не представлението победа. Използването XHR ни даде по-сигурна и все още много performant решение.

Взаимодействие с потребителя: Юи Автодовършване

След като имахме начин да получите данните в JavaScript бързо, следващото предизвикателство е да създаде начин за потребителя, за да търсите бързо през списъка с контакти. За да постигнем това, ние се обърнахме към Автодовършване контрол на Юи. Отговаря точно на нашите нужди: изключително бързо и много конфигурируеми. За да го използвате с нашите потребителски данни, ние създадохме функция, за да се използва както за автодовършване съд източник на данни, всяко натискане на клавиш в джаджа активира тази функция и преминава в низа за търсене. В рамките на тази функция, ние веригата на контактите на потребителя и се опитват да отговарят на запитването на четири различни области. Ние използваме регулярни изрази, за да направят низ съвпадение.

Дори и за големи набори от контакти, ние открихме, тази техника да бъде изключително ефективно. Тук е основната версия на това, което направихме:

  за функция searchContacts (Query) {

        VAR мачове = [],
            queryRegEx = нов RegExp (заявка "аз"), / / ​​заявка трябва да бъде
                                                 / / Проверява преди 
                                                 / / Използва в регулярен израз.
            контакт;

         (VAR N = 0 Len = contacts.length; N <Лен; N + +) {

                contact = контакти [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 на 200 милисекунди или по-може да бъде по-подходящо за XHR или други отдалечени DataSources, ние открихме, че нашата регулярен израз базирана източник на данни с местните данни е до задачата за търсене на всяко натискане на клавиш. С автодовършване, имаме свободно кеширане добавя към сместа, така че всяка дадена търсене ще трябва само да се прави веднъж.

Повече подробности за всички тези техники, включително пълни подробности за различните формати за данни и подробни данни за профили за всеки един, може да се намери на code.flickr блог.

Споделете и разширяване : Запазете си отметка към del.icio.us | Digg тя | Reddit!

В природата за 25 март, 2009

Март 25, 2009 в 9:08 ч.: Юи Екип | В В дивата природа | 3 Коментари

Новини и бележки от Юи общността в последните няколко седмици. Споделете в коментарите, това, което сме пропуснали, и ние ще го получите следващия път:

Споделете и разширяване : Запазете си отметка към del.icio.us | Digg тя | Reddit!

Georgiann Puckett: Юи / ASTRA Program Manager (AdaLovelaceDay09)

24 март, 2009 в 8:06 ч. от Ерик Miraglia, | в развитието | 1 Коментар

Dav Стъкло и Джордж на Puckett на Team Юи

[Забележка: Този пост е част от участието на отбора Юи в Ada Lovelace Ден , празник на жените технолог по целия свят.]

Georgiann на Puckett (по-известен като "Джордж") служи като ръководител на програмата за Юи и свързани проекти, включително библиотеката ASTRA). Програма за управление на сложни технически програми, състоящи се от множество проекти е един от най-взискателните работни места в софтуерна компания, и Джордж е идеално средство за предизвикателството. Тя носи на масата бързо интелигентност, търпение и дисциплина, за да управляват големи потоци от данни, и дълбоко вкоренено разбиране на процесите, чрез които се поддържат успешни софтуерни програми. Нейният фон служи добре тук, като C / C + + инженеринг ветеран, тя може се съпричастен директно с опита на инженерите, с които тя работи.

Юи пресата излизат със стотици на промени, много от които са предложени или са допринесли от фирми в целия свят. Откакто се присъедини към отбора преди две години, Джордж е революция в начина, по който тази информация се обработва. Това е довело до по-добро прогнозиране, по-добра комуникация и по-добро качество повсеместно.

Джордж също е похвално ръководството за отбора на Юи в подкрепа на основните вътрешни проекти на Yahoo. Когато се определя на вътрешен проект като "голям залог", нещо от решаващо значение за бъдещето на компанията, ние да обединят усилията си с екипа на проекта строителство на интерфейса и се уверете, че правим всичко възможно, за да ги подкрепят. Джордж управлява тези отношения, като гарантира, че нашите сътрудници получават навременни, добре документирани изгражда и че техните приоритети са точно отразени в нашите планове за изпускане. Като способността за разбиране на нуждите на различни проекти и да се улесни нашите успешни сътрудничества никак не е малко предизвикателство, и Джордж е направил най-тежката работа, необходима, за да се гарантира, че Юи и на Astra инженери в предоставянето на подходящата подкрепа в точното време, през Yahoo.

Говорейки за въже вдигане .... Джордж е добре известно както на Yahoo, изключителен технолог и неуморен защитник на Юи, но тя също така е добре известно на тези, които често служител на Yahoo, фитнес зала. Вие ще намерите Джордж има четири или пет нощувки в седмицата за работа по-добре собствения си световен рекорд формата на свободни тежести.

Работа на Джордж и общия ангажимент за високи постижения със сигурност е вдъхновен от нас, които работят с нея през последните няколко години. Попитах Георги, който я е вдъхновен и я изпратих надолу по пътя към кариера в областта на технологиите.

Каква беше първата ти опит с компютри?

Бях намерение за въвеждане на предварително средиземноморската писта в колежа и имах AP смятане Разбира старши ми година като част от учебната програма на колежа подготвям. Както късмет ще го има, учителят получава безвъзмездна помощ за два компютъра на Apple, като част от съдебен процес, за да преподава програмиране на високо ниво училище. Не само ние го имаме конкурентоспособна на опитваме да направим най-надеждни функции с най-малко количество код. Първата цифрова курс електроника в колежа, където аз имам на програмните схеми на breadboard използване на асемблер запечатани на сделката.

Знаете ли, всяко женско технолог ролеви модели, които са ти повлияли?

Има две жени, съм работил, че съм впечатлен от и научих много от. Darragh Muldoon, съосновател на Крикет Софтуер, ме наеха от колежа от най-невероятно приключение за стартиране на кариерата ми. Тя е не е технолог сама по себе си, но аз научих много от нея по отношение на народа си умения във водещи технически хора, изграждане на екипи, и отглеждане на компанията. Другата жена, аз гледам и научих от Шийла Брейди, който се вдигна в йерархията на директора на ниво в дивизия система на Apple софтуер. Тя определено знае как да управлява съобщение, в много случаи, водещи отбори, съставени предимно от мъжки инженери. Тя показва ниво на доверие, компетентност, и агресивност, които биха могли да бъдат оценени от всеки инженер - мъж или жена.

Споделете и разширяване : Запазете си отметка към del.icio.us | Digg тя | Reddit!

Джени Хан Донъли: Юи инженер (AdaLovelaceDay09)

March 24, 2009 at 8:05 am by Eric Miraglia | In Development | 3 Comments

Jenny Han Donnelly, Sr. Engineer, Yahoo; author of YUI DataTable, DataSource and AutoComplete

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

Споделете и разширяване : Запазете си отметка към 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.

Споделете и разширяване : Запазете си отметка към del.icio.us | Digg тя | Reddit!

Next Page »
Поместено от Yahoo!

Copyright © 2006-2012 Yahoo! Inc. Всички права запазени. Декларация за поверителност - Условия за ползване

Осъществено от WordPress на Yahoo! Уеб хостинг .