О модальных окнах написано уже, наверное, тонны литературы, но на написание этого топика меня сподвигла вот эта статья на хабре. В ней осталось много недосказанного, в том числе горизонтальные скачки как страницы, так и модального окна.
Конечно, можно было бы просто отписаться в комментарих, мол, сделайте так-то и так-то, и все будет тип-топ. Но мой комментарий разросся до размеров новой статьи, с наглядными примерами и комментариями.
Кому стало интересно — добро пожаловать под хабракат!

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

• Выполняет одну и только одну задачу: вывод дат в разных, потребных юзеру форматах;
• Работает в nodejs и в браузерах. В браузерах может работать как requirejs/amd-модуль;
• Не мусорит в прототипах встроенных объектов;
• Написана в strict mode;
• Обильно аннотирована в js-doc-формате;
• Не имеет внешних зависимостей.

Примеры использования:

datef('dd.MM.YY', new Date()); // "13.08.12"
datef('dd.MM.YY'); // второй аргумент необязателен — берется «сейчас»

var d = new Date();
d.setFullYear(2045);
datef('dd.MM.YYYY', d); // "13.08.2045"

// есть несколько заранее заданных форматов:
datef.formatters.ISODateTimeTZ(); // "2012-08-13T15:01:29 -04:00"

// можно определить и сохранить свой…
datef.register('myFormat', 'd.M.YY');
datef.formatters.myFormat(); // "13.8.12"

// или просто получить его как отдельную функцию
var myFormat = datef.createFormatter('d.M.YY');

Почти месяц назад вышла вторая версия прекрасного и замечательного jQuery Notification plugin для вывода самых разнообразных уведомлений на сайте, странно что Хабр вообще обошёл его стороной, исправлю ситуацию.

В первой части был реализован базовый функционал админки на javascript-фреймворке AngularJS — загрузка данных из бэкенда, добавление/изменение записей. Во второй части мы рассмотрим реализацию сортировки таблицы и разбитию по страницам, удаление записей.

При создании сайтов часто возникает задача создания админки для редактирования контента. Задача, в общем, тривиальная, но сделать удобную админку не так-то просто.

Под удобством в первую очередь подразумевается возможность сортировки таблицы со списком материалов и работа без перезагрузки страницы. Если материалов в таблице становится много, то возникает задача разбивать её на страницы.

Всем известный jQuery-плагин tablesorter с tablesorterPager-ом и менее известный, но гораздо более функциональный DataTables хороши, но обладают некоторыми недостатками. Главный из них — сложность динамического добавления новых строк в таблицу (после добавления строки в таблицу, новая строка потеряется при следующем вызове сортировки). tablesorter вообще не даёт средств для добавления строки в свой кэш, DataTables предоставляет широкое и функциональное API для управления внутренним представлением таблицы, но это API довольно многословно и не очень гибко.

Хочу предоставить общественности реализацию админки на относительно новой javascript-фреймворке AngularJS. Будет создана страничка для редактирования списка вопросов, разбитых по категориям и отвечающим. В статье нет сравнения с другими подобными фреймворками, но нет и простого повторения официальной документации, я постараюсь поделиться своим опытом в использовании фреймворка и расскажу о нескольких интересных приёмах работы с ним.

Сразу приведу, что получится в итоге (кликабельно):

Это перевод оригинальной статьи Designing for touch



Принципы управления привычными интерфейсами настольных систем оказываются перевернуты с ног на голову, когда дело касается интерфейсов сенсорных. В данной статье приводятся рекомендации специалиста по проектированию взаимодействий Джоша Кларка (Josh Clark) относительно разработки интерфейсов для сенсорных мобильных устройств и сравниваются сенсорные интерфейсы устройств Android, iPhone и iPad.

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

Оригинальная статья Джона Грэхем-Камминга.
Переведено и опубликовано с разрешения автора.

Я занимаюсь программированием уже более 30 лет, начиная с машин, уже устаревших (на процессорах Z80 и 6502) до современных, используя языки BASIC, ассемблера, C, C++, Tcl, Perl, Lisp, ML, occam, arc, Ruby, Go и многие другие.

Далее следует список того, чему я научился.

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

Как и любому front-end разработчику, мне почти в каждом проекте приходится сталкиваться с клиент-серверными протоколами – без них никак. И очень, крайне часто приходится работать с плохо продуманной архитектурой.

Также очень часто разработка протокола и архитектуры ложится на плечи веб-разработчика, что не всегда верно – она в большинстве случаев должна разрабатываться только совместно с теми, кто под эту архитектуру будет подстраиваться. К сожалению, работая за последние три года на нескольких десятках проектов, мне доводилось участвовать в планировании этого участка архитектуры только 3 или 4 раза – во всех остальных случаях она уже была предоставлена в разной степени готовности заказчиком. А ведь насколько мир мог бы быть лучше!

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

В частности я представлял углубленный анализ Angry Birds VS Tap Pet Hotel и того, как премиальные игры за $0.99 оказались побеждены бесплатными играми. Теперь это звучит очевидно, но хочу напомнить, что это было 12 месяцев назад и во время этого вебинара Tap Pet Hotel было лишь несколько месяцев отроду. Многие люди на вебинаре на самом деле не понимали как работают социальные игры.

Магазины приложений прошли через два этапа. Второй этап завершился около 6 месяцев назад.

Этап 1 в монетизации приложений был обусловлен платными играми (по 0.99 за игру).

Этап 2 это «Free to play» и сейчас такие приложения правят магазином.

Этап 2 в жизни App Store: падение Злых Птиц

Никакая из игр серии Angry Birds сейчас не входит в Топ-50 самых прибыльных приложений на iPhone. Самой близкой к чарту является оригинальная игра на 52 месте:

Вместо предисловия

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

Много полей ввода для ввода email адреса

На форме авторизации находится некоторое число полей ввода привязанных к сетке.
Ключ для входа — это связка: email + ключ.
Например:
pupkin@mail.ru
F2C1
Логин записываем в ячейку F2, адрес почтового сервера с собакой — в ячейку C1.

Одна из постоянных проблем верстальщиков адаптивных сайтов — это задача удобно представить обычные таблицы на мобильных устройствах. Вот как выглядят такие таблицы чаще всего:


Не очень удобно, правда? К счастью уже существует несколько хитрых способов решить такую проблему.

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

Сейчас многие покупают точки доступа 802.11n, но хороших скоростей достичь удается не всем. В этом посте поговорим о не очень очевидных мелких нюансах, которые могут ощутимо улучшить (или ухудшить) работу Wi-Fi. Всё описанное ниже применимо как к домашним Wi-Fi-роутерам со стандартными и продвинутыми (DD-WRT & Co.) прошивками, так и к корпоративным железкам и сетям. Поэтому, в качестве примера возьмем «домашнюю» тему, как более родную и близкую к телу. Ибо даже самые администые из админов и инженеристые из инженеров живут в многоквартирных домах (или поселках с достаточной плотностью соседей), и всем хочется быстрого и надежного Wi-Fi.
[!!]: после замечаний касательно публикации первой части привожу текст целиком. Если вы читали первую часть — продолжайте отсюда.

В наши дни сложные Javascript-приложения можно увидеть повсюду. Со временем они становятся все сложнее и уже неприемлемо просто писать цепочку callback-функций на jQuery. Javascript-программисты постепенно узнают то, что обычные разработчики знали уже несколько десятилетий. Организация и эффективность может сыграть важную роль при разработке. Таким образом, такие MVC-фреймворки на Javascript, как Backbone, Knockout и Ember появились для того, чтобы заполнить пустоту между начинающими, средними и опытными разработчиками. Они предлагают разные возможности и функционал, который подойдет разным людям, в зависимости от их потребностей.

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

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

AngularJS создан для тех разработчиков, которые считают, что декларативный стиль лучше подходит для создания UI, а императивный — для написания бизнес-логики.

Дзен Angular

• Хорошо отделять манипуляцию DOM-ом от логики работы приложения. Это существенно улучшает тестируемость кода.
• Хорошо считать, что автоматизированное тестирование приложения настолько же важно, насколько и написание самого приложения. Тестируемость очень сильно зависит от того, как структурирован код.
• Хорошо отделять разработку клиентской части от серверной. Это позволяет вести разработку параллельно и улучшает повторное использование на обеих сторонах.
• Хорошо, когда фреймворк ведет разработчика по всему циклу разработки приложения: от проектирования UI через написание бизнес-логики к тестированию.
• Хорошо, когда распространенные задачи становятся тривиальными, а сложные — упрощаются.

AngularJS представляет собой комплексный фреймворк. В стандартной поставке он предоставляет следующие возможности:

• Все, что вам нужно для создания CRUD-приложений: data-binding, базовые директивы для шаблонов, валидация форм, роутинг, deep linking, повторное использование компонентов, dependency injection, инструменты для взаимодействия с серверными (RESTful) источниками данных.
• Все, что вам нужно для тестирования: средства для модульного тестирование, end-to-end тестирования, mock-и.
• Шаблон типового приложения, включающего в себя структуру каталогов и тестовые скрипты.

AngularJS разрабатывается сотрудниками Google и используется, как минимум, в одном сервисе Google — DoubleClick.

Если по-честному, то эта статья не должна являться продолжением первой моей статьи о мгновенном изменении языка iOS-приложений. Если первая статья была написана программистом для программистов, то в этой заметке пойдет речь непосредственно о процессе локализации, применимом к любой мобильной (и не очень) платформе.

Но мы меня простим и сделаем вид, что это цикл статей ;).

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

Попробуем ответить на каждый из этих вопросов по отдельности.

После пяти с половиной месяцев разработки с момента выхода предыдущей версии, очень рад наконец представить вам Leaflet 0.4 — новую версию легковесной JavaScript-библиотеки для интерактивных карт, которая одинаково хорошо работает и на десктопных браузерах, и на мобильных устройствах.

Этот релиз, к которому приложило руку 33 разработчика, несёт в себе более простой, удобный API и громадное множество улучшений и исправлений вместе с масштабным обновлением документации, запуском официального блога и страничкой плагинов. Давайте рассмотрим улучшения по порядку.

Очень часто модальные окна и диалоги делаются при помощи плагинов jQuery. Например, SimpleModal или jqModal. К сожалению, все они, в варианте по умолчанию, работают неправильно.

Что же такое «правильно»?

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

1. Пользователю нельзя позволять прокручивать страницу под ним.
2. При этом, если содержимого в модальном окне очень много, нужно позволить прокручивать содержимое.

По этому принципу работает просмотр фото в Facebook и Вконтакте и, я считаю, что для модальных окон это правильный вариант.

Чтобы не мучать вас заранее деталями реализации, покажу сначала демо плагина jQuery: http://rmcreative.ru/playground/modals_plugin/demo.html.

Ну а теперь немного про реализацию.

У всех на слуху истории успеха, как разработчик-одиночка выпускает приложение для iPhone или iPad, оно становится хитом и приносит кучу денег. Но в реальном мире ситуация иная: в App Store чрезвычайно высокая конкуренция, и даже создание отличной программы не гарантирует, что вы окупите затраты.

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

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