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

UPD: Продолжение статьи с примером техзадания

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.

То описание технического задания, о котором речь пойдет ниже, не является пересказом ГОСТа, но скорее является его творческой переработкой, хорошо сдобренной горьким опытом. Описанный ниже подход к ТЗ не охватывает все аспекты сайтостроения, но задает общее направление.

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

1. Обоснование необходимости ТЗ

А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

Разработчик отчетливо представляет, что нужно сделать, а сделать, в его понимании нужно вот так:

Что такое?

Выполнение действий над элементами графического интерфейса в случайном порядке.

Для чего нужно?

Человек, выполняющий тестирование, это Homo sapiens, т.е. он обладает неким интеллектом. Этот самый интеллект, мешает (очень редко, но мешает) ему находить «нелепости поведения» приложения связанные с непредвиденными ситуациями. Он просто не может представить себе настолько нелогичную ситуацию.
Пользователь же, намного превосходит QA в количестве и может значительно уступать ему в IQ. Отсюда, вероятность непредвиденного поведения пользователя отнюдь не крайне мала.
Итак, что нам, обладая свободными ресурсами и желанием, мешает принять меры по предотвращению подобных ситуаций? — Ничего.
Теперь сформулируем конкретные задачи, в которых «бессмысленное клацанье» по кнопкам может быть полезно:

• Дополнить существующее тестирование стабильности приложения путем введения модели нелинейного поведения пользователя в GUI.
• Исследовать потребление ресурсов при всех возможных вариантах работы приложения (инициированные из GUI).

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

Как делать будем?

Дальнейшее описание предназначено для тестирования приложений на платформе Windows.
Предлагаю воспользоваться связкой python + pywinauto. Хотя pywinauto и имеет некоторые ограничения в плане доступа к элементам окна, для большинства случаев этого должно быть достаточно.
Честно говоря, альтернативы я не вижу. Все знакомые мне средства автоматизации тестирования GUI не обладают динамичностью, показанной ниже – уже во время выполнения теста получать список контролов, определять их тип и выполнять допустимое действие.
Также не стоит недооценивать возможностей самого Питона и его модулей. Тут вам можно и видео снять, CPU замерить и сообщение, куда надо, в случае чего отправить…

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

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

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

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

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

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

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

По мотивам вчерашнего поста в блог Сбербанка про то, как они собираются повышать свой «низкий уровень клиентского обслуживания». Уже когда я читал собственно этот самый регламент (не буду врать, дальше первой страницы я так и не прочитал), у меня в голове вертелись мысли в стиле «а давайте введём штрафы за бедность — бедным быть станет невыгодно, и все разбогатеют».

Сегодня я понял причину своего скептицизма, когда вспомнил новый интерфейс банкоматов Сбербанка (который был с помпой анонсирован год назад).

Знаете, как издалека опознать неработающий банкомат Сбербанка? Если очереди нет — банкомат Сбербанка не работает. Обратное неверно (если очередь есть — банкомат Сбербанка всё равно может не работать). Казалось бы, банкоматов Сбербанка в Москве нереальная куча, откуда очереди?

Не один раз в комментариях замечал что народ негодует по поводу того, что веб-разработчики стали злоупотреблять использованием Bootstrap от Twitter. Признаюсь, я и сам успел закончить несколько небольших веб-приложений с использованием этого набора скриптов и стилей. Я не против использования Bootstrap от Twitter, я против злоупотребления этим когда есть столько хороших альтернатив. Я почти каждый день натыкаюсь на интерфейсы, построенные на Twitter Bootstrap, и это начинает напрягать. Последней каплей для поиска альтернативы стало изменение интерфейса биллинг панели моего хостера на шаблон Bootstrap. В этой записи я хотел бы немного рассказать про одну из альтернатив — HTML KickStart.

Аннотация

В статье я попробую рассказать о том, как на базе Twitter Bootstrap можно очень легко реализовать приятный пользовательский интерфейс небольшого (одностраничного) web-приложения, владея лишь базовыми знаниями html. Сразу предупреждаю, специалистам будет не интересно, речь пойдет о базовом стандартном функционале.

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

• Грамотно обрабатывайте запросы на изменение требований
• Урезайте лишний функционал
• Управляйте рисками
• Используйте гибкие методологии
• Научитесь управлять Death March проектами

Microsoft опубликовала демо-страницу улучшенной типографики для формата OpenType. Это альтернативные глифы, лигатуры, кернинг, дроби, малые прописные и минускульные цифры. Эффекты видны, если наводить на текст мышкой. Демо хорошо работает только в браузерах с поддержкой OpenType, сама Microsoft рекомендует IE10+ и Firefox 8+. В других браузерах могут проявиться не все эффекты, это ещё зависит от операционной системы.


^{Альтернативные глифы и малые прописные}

С Microsoft можно согласиться — OpenType действительно поднимает оформление текста в вебе на новый уровень, близкий к типографскому. Возможности этого формата явно превосходят @font-face.

Представляю вашему вниманию перевод статьи под названием "User Experience and the design of news at BBC World Service" от Tammy Gur. Перевели в компании UXDepot специально для пользователей Хабрахабра с одобрением компании BBC и издания Johny Holland Magazine.

Проектирование окружающей среды для стремительного потока информации, проходящего через новостной веб-сайт в режиме нон-стоп — это вызов, не похожий ни на что другое. Команда дизайнеров и специалистов в области UX в BBC World Service создает новостные сайты для десктопных и мобильных браузеров на 27 языках, удовлетворяя различные аудитории по всему миру. В этой статье мы поделимся этим опытом с вами.

Хочу поделиться ссылками на несколько полезных сервисов. Некоторые из них помогут сэкономить время, другие — сделают за Вас незнакомую/нелюбимую работу. Список разбит по категориям, чтобы было легче ориентироваться.

Сервисы опросов
userreport.com (добавил Romanych)
simpoll.ru
webanketa.com (добавил mihass)

Кнопки постинга в социальные сети
Кнопка от Яндекса
addthis.com (добавил UksusoFF)
share42.com

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

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

Почему это глупо

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



Это скриншот из презентации «Beyond the mobile web by yiibu» (очень рекомендую).

Во-вторых, если вы не facebook или yandex, скорее всего, вы не потянете создание и поддержку разных версий сайта для каждого устройства. Да и это не имеет особого смысла. Потому что ситуация становится похожа на реалии пятнадцатилетней давности. Тогда делали сайт «под браузер», а сейчас автор предлагает делать сайт «под устройство».

Как сделать один сайт для всех устройств

Какой сайт можно считать хорошим, а какой — нет? Есть ли какие-то критерии оценки сайта, определения его качества?

В этой статье мы попробуем разобраться в этих вопросах.

Критерии оценки сайта

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

• Видимость сайта поисковыми системами
• Удобство использования сайта
• Дизайн сайта
• Функциональность

Почему я расставил критерии именно в таком порядке? Из таких соображений.

В рамках внутренних образовательных семинаров к нам в гости пришла Таня Мисютина — дизайнер интерфейсов и инфодизайнер, в данный момент руководитель группы проектирования интерфейсов в NetCracker Technolgy Corp.

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


Расшифровка и презентация

«Интерфейс гамбургера очень понятен: его просто нужно взять и съесть. В этом смысле интерфейс гречки более сложен: сначала нужно раздобыть ложку и затем уже справляться с едой».

У нас замечательные новости! Слава о результативности российских Уикендов дошла и до самих создателей формата Startup Weekend.
Идеологи и авторы международного стартап-движения приедут в Санкт-Петербург, на второй Питерский Уикенд (15-17 апреля), чтобы обменяться опытом и посмотреть, как это происходит в России.

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

Marc Nager, Clint Nelsen и Frank Nourigat, два американца и один француз, создавшие Startup Weekend, расскажут про стартапы в США, поделятся секретами, как запустить свой проект на международный рынок, и ответят на вопросы зрителей.

14 марта мы провели открытую лекцию с участием немца Марка Самвера, со-основателя фонда European Founders. Чтобы послушать человека, создавшего немецкий eBay, инвестировавшего в Facebook и LinkedIn, а ныне управляющего Groupon, люди ехали не только из разных концов Москвы. Были те, кто добрался на встречу из Воронежской и Волгоградской областей, Карелии.

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

Сегодня хочу рассказать об интересном способе получения такого эффекта с помощью css:

Демо

www.ilovepsd.ru — небольшой справочник по «Фотошопу» для веб-дизайнеров, но будет полезен и верстальщикам. Например, если вы занимаетесь версткой, то можете ссылаться на него, как на требования к макетам дизайнера.

Справочник призывает работать в «Фотошопе», соблюдая правила хорошего тона. Цель проекта — ускорить процесс дизайна, улучшить чтение файлов проекта и облегчить процесс верстки.

Полезные (и по делу) советы от комментирующих будут добавлены в проект. Велкам.

UP. Сделана фейсбук пейдж для желающих отписаться.

Представляю вашему вниманию перевод статьи "Mobile Form Design Strategies" от Chui Chui Tan. Перевели в компании UXDepot. Специально для пользователей Хабрахабра с одобрением издания UX Booth.

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

Интернет на экране мобильного телефона находится под влиянием нескольких важных факторов:

• Окружающей среды — человек может пользоваться гаджетом в толпе, в режиме цейтнота или на ярком свету (соответственно, качество изображения на экране ухудшается)
• Сети — соединение может быть медленным и ненадежным
• Особенностей девайса — например, маленького экрана устройства

Конфуций сказал однажды: «умный человек учится на своём опыте, мудрец — на чужом». В этой статье я постараюсь сделать ещё один шаг в направлении к «умному человеку» и поделиться, как можно аккумулировать свой опыт в течение проекта.

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

Как не наступать на грабли менеджеру проекта? Вопрос, на самом деле, не очевиден. Понятно, что от этого нет универсального лекарства. Первый и самый простой вариант — «это придёт с опытом». Именно поэтому, опыт — это очень ценный ресурс, потерю которого нужно минимизировать. Один из таких способов максимально сохранить опыт от прошедших проектов я активно применяю и сейчас вам его опишу. Называется он – дневник проекта.