Най-добри практики за прогресивно подобряване на уеб дизайна

Изработката на уебсайтове е изключително сложна с много бързо променящи се части. Целта на общността на уеб дизайна е да намали сложността, и намаляване на потенциала за грешка на всеки етап от процеса на създаване.

Прогресивно подобрение е такава идея в уеб дизайна, която има за цел намаляване на грешките и предоставят постоянно потребителско изживяване повсеместно. Концепцията има своя собствена страница от Уикипедия, която обяснява това като метод на напълно достъпно съдържание, визуализиране на разширени функции само когато се поддържа от браузъра.

Лесно е да се разбере прогресивното усъвършенстване, но не е толкова лесно да се приложи директно към проектантската работа. Бих искал да покрия някои най-добри практики за прогресивно подобрение в реални проекти да се помагат на дизайнерите да мислят по-устойчиво за техния работен процес.

1. Разбиране на прогресивното подобрение

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

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

Прогресивното подобрение е по-добро за цялостния потребителски опит, тъй като в основата си зарежда само необходимите елементи. Всеки уеб браузър може да поддържа текст (и обикновено изображения). Без каквато и да е CSS тази информация ще изглежда скучно и безвкусно, но ще бъде достъпна.

Това Списък Apart статия твърди, че е прогресивно подобрение съдържание и първи с стилове и динамични компоненти, добавени по-късно. Съдържанието в семантичен HTML трябва да бъде доставено преди всичко друго.

Разширените CSS и JavaScript, които използваме днес, се поддържат широко, но ако искаме да следваме принципите на прогресивното подобрение, те трябва да се разглеждат като лукс.

Ето общо обобщение на основните характеристики на прогресивното подобрение, което трябва да вземете предвид:

• Семантична маркировка за цялото съдържание
• Потребители " предпочитания на браузъра трябва да се спазват
• Съдържанието и основните функции трябва да бъдат достъпни за всички потребители
• Ненатрапчив JavaScript се зарежда само в среда, която може да я поддържа

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

Ами браузърите, които не поддържат модерен CSS3? Това е мястото, където играят сайтове като Can I Use. Трябва да решите кои характеристики са полезни за реализиране и да правите преценки на целевата аудитория на уебсайта Ви.

2. Издръжка в таблици със стилове

Повечето браузъри днес поддържат всички основни свойства, от които се нуждаете. Но напредналият CSS3 все още е проблем за старите потребители, и прогресивното подобрение предлага решение.

Вместо да търсите резервни методи, за да поддържате тези нови функции, първо се безпокойте правилно структуриране.

Напишете семантичен HTML и CSS маркировка, която работи в колкото се може повече активни браузъри (поддръжката на стари браузъри като IE5 поддръжка не е необходима).

Вземете например този JSFiddle, който използва плувки с две странични ленти (.определен) и площ на течно съдържание (.течност). Ако изтриете всички CSS и повторите кода, ще забележите, че всичко се подрежда добре с първата колона, след това с втората и накрая с последната.

Някои разработчици предпочитат да имат колона със съдържанието (.течност) се появяват първо в HTML. Това е мястото, където прогресивното усъвършенстване идва и алтернативните CSS решения стават жизнеспособни.

Двете основни цели на HTML са следните:

• напълно семантичен и валиден код
• А последователен опит за всички

Най-простият начин за постигане на тези цели е да започнете от нищо и работи, тъй като най-прогресивните застъпници биха го препоръчали.

Ако вашият код изглежда добре с CSS и е забранен и активиран, тогава той предлага разумно решение за всеки.

Заслужава си да се обмисли в кой момент отпадате подкрепата за нещо. Microsoft вече е намалила основната подкрепа за IE6, така че потребителите, които изпълняват този браузър, може да не си струват времето.

Но все още има един голям въпрос: ако браузърът не поддържа моята модерна CSS, какво трябва да направя?

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

Вие не се нуждаете от резерви, защото сте основно предполагайки, че нищо не се поддържа по подразбиране.

Методите за прогресивно подобрение са за това, сайтът да се използва дори и в случаите, когато нещо не се поддържа, но ако се поддържа, толкова по-добре.

Трябва да помислите как съдържанието всъщност се движи без CSS. Например, когато деактивирам CSS на уебсайта на Transmit, съдържанието все още се движи органично надолу по страницата.

Да, това е грозно, и да, чувствам, че сме загубили двадесет години напредък ... но работи.

3. Работа с JavaScript

Струва си да споменем, че всеки проблем с JavaScript, с който можете да се сблъскате по време на процеса на разработване, е сложен и уникален. Когато изграждате нов проект с прогресивно подобрение, трябва да изброите всичките си необходими JS-базирани функции и да обмислите как биха могли работят без JavaScript.

Това ще изисква много онлайн изследвания за намиране на валидни решения. Aaron Gustafson написа страхотен блог с решения на различни проблеми, като например замяна на Ajax с метаобзавеждане за съдържание вътре в iframe.

Също така, когато създавате JavaScript раздели, е добра идея използвайте свързващи връзки с реални стойности на ID. По този начин, когато JavaScript е деактивиран, можете да оставите разделите видими и достъпни чрез стойността на котвата. Aaron написа още едно парче на A List Apart, което обхваща по-общ преглед на това как трябва да мислите за тези проблеми.

Ето още един пример. Да предположим, че имате връзка, която динамично зарежда съдържание. Най- HREF Стойността е празна, защото всичко се зарежда чрез JavaScript с метода preventDefault ().

Вместо това би било разумно да се постави HREF собственост посочете друга страница където съдържанието може да се зареди естествено, но посетителят вижда тази страница само, когато JavaScript е деактивиран.

Прогресивното подобрение е повече от JavaScript, но с напредването на уеб разработките всяка година, няма съмнение, че JavaScript играе важна роля.

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

Също така мисля за JavaScript функции, които липсва изчерпателна поддръжка на браузъра. Това включва API за извличане, API за натискане, синтаксис на функцията за стрелки или дори браузъри без поддръжка за модерни библиотеки като jQuery.

Всяка функция изисква индивидуално тестване с индивидуално решение.

Същността на постепенно подобрения JavaScript е към изграждане на съдържание, което функционира без скриптове. Това може да доведе до елементарен потребителски опит, но това е наред, докато уебсайтът е използваем и съдържанието е достъпно.

Ако искате да направите тест на живо, обикновено можете деактивирайте CSS и JavaScript във всеки основен браузър за да видите как работи уебсайтът ви. Също така си струва да обмислите използването на разширения като A-Tester за спазването на WCAG.

JavaScript с прогресивно подобрение е огромна тема. Ето някои публикации, които да ви помогнат да копаете по-задълбочено:

• Прогресивно подобрение! = “Няма JavaScript”
• Взаимодействието е ключово: прогресивно подобрение и JavaScript
• Прогресивно подобрение: За съдържанието
• Как да прилагаме прогресивно подобрение Когато JavaScript изглежда като изискване

Където прогресивното повишаване намалява

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

Така например, тази методология не е добро решение за уеб приложения, които функционират единствено за повиквания на Ajax. Това ли е добър избор за достъпност? Не разбира се, че не. Но ако това беше така, повечето уроци на Codrops дори нямаше да съществуват. Ти трябва да запомни целевата аудитория.

Вероятно бизнес сайтът няма аудитория, която да се интересува от лъскавите нови CSS3 перспективни свойства, но уеб разработчиците могат да бъдат идеалната аудитория за такива разширени функции.

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

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

Допълнителна информация

Ако непрекъснато изграждате уеб проекти, трябва да обмислите прилагането на прогресивно подобрение в работния процес. Това е много по-лесно, отколкото изглежда на пръв поглед, и всичко започва с основите. Повечето теми, свързани с прогресивното подобрение, просто изискват практика и тестване. Изпробвайте предложенията от тази статия и вижте какво работи най-добре за работния процес.

Ако искате да научите повече за прогресивното подобрение, разгледайте тези свързани публикации:

• Разбиране на прогресивното подобрение
• Прогресивно подобрение: какво е то и как да го използваме?
• Проблемът с JavaScript-зависимостта: преодоляване на прогресивното подобрение на мита