От переводчика

С удовольствием ознакомился с этими рекомендациями и теперь предлагаю вам перевод.

Введение

Это руководство описывает правила для оформления и форматирования HTML и CSS кода. Его цель — повысить качество кода и облегчить совместную работу и поддержку инфраструктуры.

Это относится к рабочим версиям файлов использующих HTML, CSS и GSS

Разрешается использовать любые инструменты для минификации компиляции или обфускации кода, при условии, что общее качество кода будет сохранено.

От переводчика: Это полный перевод статьи Ars Technica, малая часть которой была приведена вчера многоуважаемым alizar. Нам кажется, что в ней содержится много интересных фактов, упущенных в кратком изложении.

Нет недостатка в историях об одиноких разработчиках, которые разработали приложение для iPhone или iPad и заработали ошеломительный успех. Но в реальном мире большинство разработчиков мобильных приложений не выходят на точку безубыточности, говорит последнее исследование маркетинговой фирмы App Promo. Хотя методология исследования немного приукрашивает картину, многочисленные разработчики, с кем мы говорили, описали результаты — 59% приложений не приносят прибыли, а 80% разработчиков не могут поддерживать бизнес только на приложениях — как довольно точные.

Большие ожидания

Apple часто хвастается тем, что App Store предлагает пользователям сотни тысяч приложений на выбор. Однако, несмотря на то, что большое разнообразие помогает пользователям, быть замеченным на большом рынке может быть гораздо труднее для небольших разработчиков.

«В течение лет я вижу как заметность приложений, над которыми я работаю, заметно снижается», — говорит разработчик Пат МакКаррон. «Прямо сейчас ваше приложение никогда не будет замечено, если вы не попадете в список Топ-100 или Топ-200. Пользователи не хотят вечно листать вниз для поиска вашего одинокого приложения в конце списка».

Пол Кафасис из Rogue Amoeba согласен с тем, что App Store все больше становится лотереей, давая меньше шансов преуспеть маленьким разработчикам по сравнению с зарекомендовавшими себя компаниями.

Оказывая помощь в выводе разработок и бизнесов на внешние зарубежные рынки, приходится постоянно наблюдать одни и те же ошибки, и как следствие — неудачи и потери.

Большинство специалистов, принимающих участие в проектировании и разработке пользовательских интерфейсов, давно запомнили простую истину — «интерфейс создается для конечного пользователя». А значит, пользователя нужно любить, лелеять и внимать каждому его отзыву. Но бывают случаи, когда юзабилист не должен слушать пользователя, давайте поговорим о проектировании интерфейса для профессиональных систем.

В оригинале название звучит как «How Not To Sort By Average Rating». Я подумал, что дословный перевод «Как не сортировать по усреднённому рейтингу» будет малопонятен и хуже отражает содержание статьи.

Постановка проблемы

Вы занимаетесь веб программированием. У вас есть пользователи, которые оценивают контент на вашем сайте. Вы хотите разместить высоко оцененный контент наверху, а низко оцененный — внизу. Для этого на основе пользовательских оценок вам нужно вычислить некий «рейтинг».

Неправильное решение №1

Рейтинг= (Число положительных оценок) - (Число отрицательных оценок)

Мы уже писали о методах (Mobile First и Response Web Design), которые используем при разработке нашего сервиса. В этой статье я хочу поделиться с вами нашим опытом. То, что в теории кажется простым, на практике порой оборачивается кошмаром. Речь пойдет о том, как нам удается создавать универсальный веб-сервис, способный работать на большом количестве устройств.

UPD. Для краткого введения в адаптивный дизайн рекомендую прочитать статью «Как сделать один сайт для всех устройств (Responsive Web Design)».

Перевод крайне ценной статьи «Responsive Web Design Techniques, Tools and Design Strategies» популярного интернет-издания для разработчиков Smashing Magazine.

Еще в январе мы опубликовали статью об адаптивном дизайне «Responsive Web Design: What It Is and How To Use It» (Адаптивный веб-дизайн: Что это такое и как им пользоваться). Адаптивный веб-дизайн продолжает привлекать к себе много внимания, но, учитывая, насколько он отличается от традиционных методов разработки сайтов, он может показаться заоблачно сложным для тех дизайнеров и разработчиков, которые его не пробовали.

По этой причине мы составили обзор ресурсов, полезных при создании адаптивных сайтов. В обзор вошли подробные руководства, подходы, инструменты, статьи, содержащие практические советы, необходимые для создания вашего собственного адаптивного сайта.

Техники Responsive web design

1. CSS Transitions and Media Queries
CSS Transitions и Media Queries

Elliot Jay Stocks подробно рассказывает о методе сочетания CSS Media Queries и CSS transitions. Основная идея в следующем: разрабатывая адаптивный сайт с помощью Media Queries, вы постоянно изменяете ширину вашего браузера, чтобы посмотреть, как сайт ведет себя при этом. Но каждый раз, когда отрабатывает один из ваших Media Queries, виден жесткий переход между стилями (первый, например, для десктопов, второй — для планшетов). Почему бы не использовать CSS transitions для сглаживания этих жестких переходов с помощью анимации?

Появилось желание сделать свое приложение — быстро дешево и максимально полезно. Начал собирать информацию о современных инструментах разработки. Чтобы не потерять, а так же получить отзывы, мнения, комментарии и вообще любую полезную информацию, оформил в виде статьи.
Планирую использовать некоторые инструменты, и позже написать по ним более развернутый обзор. Итак, встречайте

1. Appmakr
appmakr.com
Платформы: iOS
Стоимость: free-$999, FREE- if you submit yourself to your own app store
Дополнительные услуги: Бесплатный доступ к ресурсам сайта.
Описание: Appmakr.com — веб-приложение, которое поможет вам создать приложения для айфона быстро и просто.
Замечания: Если вы не знаете как создать приложение для айфона, вы можете запросить помощь по телефону.
Владельцы могут размещать рекламу в своих приложениях и зарабатывать на ней.

Любой, кто играл или наблюдал за игрой друзей, либо в принципе видел игры, которые были выпущены в 80-90-х годах, должны быть знакомы с техникой параллакс-скроллинга.

Вспомните такие игры, как Mario Bros, Streets of Rage, Mortal Kombat, Turtles in Time или оригинальную игру Moon Patrol. В этих играх техника параллакса наблюдается в тот момент, когда несколько фоновых слоев с различными текстурами двигаются с разной скоростью, что создает эффект трехмерного пространства.

Почему я начал говорить о ретро-играх в статье о веб-разработке? Самым простым ответом мог бы быть «потому что они клевые», но нет. Параллакс-скроллинг является классным дизайнерским концептом, который прокладывает свой путь в мир веб-дизайна. Nike были одними из первых, кто использовал эту технику с большим успехом, когда они наняли маркетинговых гигантов Weiden and Kennedy для разработки их оригинального сайта Nike Better World. Сайт Nike Better World с того времени был обновлен и заменен на новый, однако есть другой сайт, довольно похожий на то, как выглядел первый параллакс-дизайн от Nike — сайт о спортивных напитках Activate.

Приветствую всех.

Недавно наш хабраколлега опубликовал интересную статью об адаптивной разметке.
Уже не далеко то время, когда мы будем уделять верстке под все разрешения намного больше внимания, нежели делаем это сейчас. Посему считаю нужным подходить к этому периоду подкованным в данном вопросе, ну или хотя бы иметь четкое представление, что это такое и с чем его едят. Запасаемся смартфонами и таблетками.

Где-то год назад при разработке нашего проекта мы дошли до некой точки развития, когда или начинается кропотливая настройка и оптимизация MySQL-сервера, или начинается опять же кропотливое изучение запросов, которые идут в БД. Так получилось, что именно тогда был бум статей про MongoDB, CouchDB и прочие NoSQL базы данных и соблазн попробовать их на живом проекте был крайне велик.

При выборе главную роль сыграла фраза «CouchDB предназначен именно для веба», а также то, что для доступа не требовались никакие прослойки — доступ осуществляется по любимому мной REST, а API выглядит очень простым и изящным. Вдобавок к этому CouchDB имеет крайне удобный веб-интерфейс для администрирования Futon, чего на тот момент не было у MongoDB, а также железную устойчивость к падениям.

Забегая вперед скажу, что выбор полностью себя оправдал — мы избавились от огромного количества проблем при разработке и проектировании БД, код проекта сильно упростился и стал гораздо лучше структурирован, но самое главное — тот самый поворот в сознании, который нам дал CouchDB. За это время я лично набил множество шишек при разработке и хотел бы поделиться опытом с Хабрасообществом. Эти советы не для начинающих — это советы по использованию CouchDB на живом production.

Последнее время все чаще можно встретить сайты с необычным дизайном и функциональностью, увидев которые, можно залипнуть на некоторое время. Увидев такие, у меня рука непроизвольно тянется к f12, чтобы открыть firebug и посмотреть, как же реализован тот или иной компонент. Таким образом можно открыть для себя интересные техники и в будущем реализовать их на своих проектах. Некоторые из них стали доступны с приходом новых технологий, например таких, как CSS 3 — то, что раньше было реализовано на флеше, теперь можно воплотить с помощью строк кода в таблице стилей. Дизайнеры тоже не теряют времени, создавая новые тренды и все плотнее взаимодействуя с верстальщиками. В этой статье я хотел бы показать 15 сайтов, которые так или иначе удивили и порадовали меня. Возможно, кого-то они вдохновят на собственный шедевр

Проверка приложения, отправленного разработчиком на рассмотрение Apple Review Team в iTunesConnect в среднем занимает около недели, а если вам «повезло» и вы отправили ваше приложение около выходных или праздников, то процесс проверки и появление заветного «In Review» может затянуться на гораздо больший срок.
В данный статье я хочу описать два способа ускорения проверки iOS и Mac приложений в AppStore, работающих на сегодняшний день. Оба способа являются бесплатными.

Предлагаю вашему вниманию вольный перевод статьи Avi Itzkovitch Designing Experiences for Young Kids: Child Proofing your Application

Мне недавно посчастливилось работать над интерактивной книгой для детей дошкольного возраста (2-5 лет) для платформ IPad и Android. При проектировании для маленьких детей необходимо смотреть на вещи с точки зрения ребенка, и, в процессе работы над проектом, я получил для себя несколько важных уроков.
Дети любопытны и хотят все исследовать. Как правило, они касаются руками всего, что видят, и могут заметить то, что взрослые обычно не замечают. Например, дети не подвержены баннерной слепоте, для них это еще одна возможность узнать, что произойдет, если на него нажать. Большинство проблем у молодых пользователей вызывает возможность перемещаться в приложении, потому что они боятся нажать что-то не то. Реклама, случайное прикосновение или просто кнопка меню могут затруднить пользование приложением ребенку.

Пару лет назад я сильно заинтересовался UX и всем, что с ним связано. Постепенно пришло понимание, насколько важна визуализация информации, особенно сейчас. Прочитав Тафти, Кливеленда и Бертена, просто невозможно не думать в этом направлении. Постоянно приходят в голову идеи, как сделать вещи (в частности, в нашем продукте) более визуальными, более понятными.

Ниже я попытался показать, почему визуализация информации важна, рассказать о ее базовых принципах и показать несколько классных примеров. Заранее прошу прощения за парочку скучных определений и отсутствие шуток в статье. Это сделано намеренно. Статья дэдли сериоус.

И, как обычно, прощу прощения за объем статьи. Но, надеюсь, вам будет интересно дочитать до конца.

Здравствуй, дорогой хабрадруг! Сегодня существуют более тысячи способов создать кнопку; чтобы понять их сущность, вам нужно лишь потратить немного времени, просмотрев работы на сайте dribbble.com. Большинство из этих примеров очень похожи друг на друга, однако время от времени попадаются и такие кнопки, на создание которых потратили чуть больше внимания, времени и сил.



Воспользовавшись замечательными параметрами CSS3, мы можем создать элегантые и стильные кнопки без особых усилий (учитывая старые браузеры, конечно). Создаете ли вы кнопку непосредственно в CSS или пользуетесь специальными инструментами для их создания, всегда нужно тщательно подумать о том, как ваша кнопка будет выглядеть в контексте веб-сайта.

Ближе к двум часам ночи в голову в месте с мыслями о вечном приходят не менее вечные вопросы — «в чём смысл жизни ?», «зачем вообще человеку спать ?» или «Какого чёрта эта #%^$ не работает ?» и чем ближе утро, тем сильнее начинает волновать именно этот самый последний вопрос.

Чуть ниже я расскажу о том какого чёрта сss селекторы иногда не ведут себя так, как нам кажется правильным, и о том как они на самом деле должны себя вести.

Недавно случилось так, что мы должны были начинать новый интернет-проект, но все наши опытные дизайнеры на то время были заняты другими проектами. Т.к. мы в основном специализируемся на разработке коммерческих программ, не все наши специалисты хорошо понимают тонкости дизайна мобильных сайтов. По-этому, я провела подробный мастер-класс с большим количеством скриншотов и слайдов.

Эти 70 шаблонов проиллюстрированы сотнями примеров приложений для операционных систем Apple, BlackBerry, Android, Symbian, Windows и WebOS будут изданы O’Reilly Media как «Mobile Design Pattern Gallery». Ниже приведена одна из моих любимых глав — Приглашение.

* Не смотря на то, что эти шаблоны ориентированы на разработку мобильных приложений, они так же могут быть использованы при работе над мобильным веб-сайтом.

Каждому, даже самому «молодому» верстальщику известны неприятности (проблемы) с интервалом между элементами, пробелами, которые вставляются между словами. Эти пробелы часто мешают нам при вёрстке того или иного блока. Избавиться от них бывает не так-то просто, а зачастую эти межсловные расстояния и вовсе ставят нас перед выбором, выбором способа решения данной проблемы.

В этой статье мы попытаемся понять, что же из себя представляют эти загадочные "Отступы", что это за звери и с чем их едят. Так же рассмотрим, что такое inline-block, и почему после себя он ставит эти непонятные интервалы. Ну, и, самое главное, мы увидим несколько универсальных решений данного вопроса и, конечно же, обсудим все их стороны.

Привожу перевод статьи Ника Карсона. В статье собраны вместе, как мне кажется, основные правила построения интерфейса для iOS приложений.

1. Возможно, сенсорное управление отличается гибкостью и интуитивностью, но оно далеко не совершенно. Подумайте, чем люди занимаются, когда используют ваше приложение, и как они держат устройство. Помните, что пальцы покрывают гораздо большую площадь, чем кажется, и их точность оставляет желать лучшего.

2. Ориентируйтесь на устройство при создании приложений: учтите не только размер экрана, но и где и когда устройство используется. Больше всего iPad используется для развлечений между 8-11 часами вечера, перед сном, тогда как iPhone — в очереди на автобус или в кофейне. Учтите различные сценарии использования при разработке приложений – включая и то, как далеко устройство расположено от лица пользователя.

3. Рассматривайте ваше приложение поэкранно. Определите, каковы основные задачи, которые достигаются при использовании данного активного экрана, и затем сделайте так, чтобы пользователь мог решить их, используя минимальное количество дополнительных опций, кнопок и других элементов управления. Избегайте слишком большой функциональной нагрузки на активный экран, в особенности на мобильных устройствах.

4. Разработка программ для мобильных телефонов или планшетов значительно отличается от разработки веб-приложений и даже приложений для стандартного рабочего стола, — каждый элемент занимает на экране определенное место, и это правило необходимо неукоснительно соблюдать. Рассматривайте это скорее как преимущество, чем ограничение: фиксированные шаблоны помогут лучше контролировать размер и расположение каждого элемента, видимого пользователю.

5. При адаптации приложения к экранам различных размеров, помните, что при значительном его изменении – например, от iPhone к iPad – способ использования устройства также изменится. Если размеры ограничены, используйте основные функции приложения, при их увеличении – можно включить любые дополнительные функции, которые не вошли в более сжатую версию, так как у вас появляется возможность обыграть дополнительное пространство.

За остальными 45-ю — добро пожаловать подкат.