Отличная альтернатива для jsfiddle.net — cssdeck.com. На мой взгляд удобнее. Хотя бы тем, что на run постоянно тыкать не нужно. В остальном — спасибо комментаторам и автору за интересные ссылки.
Я бы еще добавил openshift.redhat.com как альтернативу хероку, в отлиии от хероку там дается 3 «web dyno» (там они называются gear), принцип работы тот же.
у меня нет суждений и мнений в комментарии, я просто объективно взглянул на ситуацию :)
если интересует мое личное мнение (в чем я сомневаюсь) — бэм избыточен в своей сложности для 99% проектов. Почему? Да потому что нет необходимости синхронизации отдельных команд. Нет необходимости создания библиотеки общих элементов и проблем с их совместимостью.
БЭМ — это попытка прыгнуть на пять лет вперед, радостно размахивая оперенными трехметровыми костылями
Долетели ли они до цели? Да. Ржут ли над ними? Тоже да.
Потому что единственная и первоочередная задача БЭМа — это инкапсуляция классов. Вот товарищ ниже пишет, как это все появлялось: куча разных команд делала кучу разной хрени, и нужно было их совместить. Когда начали совмещать — ясен хрен что div.mega-link оказался в десяти проектах разом. Поэтому нужно было внедрить префиксы класса. Теоретически можно было бы обойтись .block-name .element-name, но возникала проблема с вложенными блоками: если в родительском блоке и дочернем блоке были .mega-link, понятное дело что к потомку применялись свойства родителя.
Таким образом единственным возможным вариантом было создание классов .block_name__element_name.
Через уже небольшое время народ задолбался от монотонности разумного в общем-то процесса до такой степени, что решил упростить себе жизнь и сделал те самые bem-tools, без которых верстать уже некоторые попросту не умеют.
Вся подстава в том, что в реальности инкапсуляция классов уже существует и работает в Chrome, а с полифиллом (я сам был в шоке, если честно) — и ie10+ и FF, safari etc. Называется решение shadow DOM. По сути — это изолированная часть документа, внутри которой есть собственная логика, скрипты и стили, при этом снаружи повлиять на них практически невозможно. Через пару лет большинство подобных блочных проектов будет разрабатываться именно на базе shadow DOM, а про БЭМ будут помнить только фанатики и на тот момент — старперы, так как объективно он перестанет быть нужен. Это не «дискасс ит», это вполне логичная цепочка заключений: БЭМ создан для того, чтобы решить проблему инкапсуляции стилей, он решает ее, при этом избыточен, имеет определенный порог вхождения, увеличивает размер выходных файлов, через ~3 года 95% браузеров как минимум с полифиллом будут поддерживать технологию, так же решающую эту проблему, но не создающую новых.
Возможно, БЭМ трансформируется во что-то еще, но в текущем состоянии он отомрет. Хотя как промежуточная технология идеологически он хорош.
— Ресурс тех же LED ламп гораздо меньше из за того что умирает «балласт».
— Светодиоды со временем тускнеют, у меня через пару лет лампочки светят раза в полтора менее ярко чем новые.
— Добиться такого же светового потока как при использовании ламп накаливания практически невозможно (либо белит, либо синит, либо желтит)
— При использовании в местах где частые включения/выключения ресурс лампы очень мал — сдыхает балласт.
Сэкономить на использовании этих ламп невозможно, за два года моего эксперимента я портатил на закупку ламп + электроэнергию столько же денег сколько тратил бы на обычные лампы накаливания + потребление.
Не из собственного:
— На изготовление «балласта», светодиода, сборку тратится несоизмеримо больше электроэнергии, чем на изготовление лампы накаливания.
— Производство «балласта», диодов гораздо менее экологическое, чем изготовление лампы накаливания.
— Про утилизацию тоже все замалчивают, если речь идет про люминесцентные лампы, то в них ртуть.
Отлично, то что нужно. Постараюсь здесь ответить кратно, а развернуто, с подробностями уже в новой статье.
1. Пока нет. Сейчас работаем с Datex'ом, должны закончить работу с ними к февралю. Для этого используем специальный японский преобразователь com to lan. Очень интересный опыт, расскажу о нем обязательно позже. Аналогично собираемся работать с Марией c февраля. 2 эти компании производят практически 85-90% всех фискальных принтеров в Украине. Для России решение будет аналогичным, просто мы чуть позже собираемся на этот рынок.
2. Мобильный эквайринг или обычный эквайринг. В перспективе уйти от физического применения карт и оплачивать счета через мобильный телефон с помощью приложения, к которому привязана карта. Сейчас ведем переговоры с несколькими банками и двумя компаниями, которые это уже делают в Украине.
3. При новой поставке продуктов автоматически пересчитывается все себестоимости блюд с учетом % наценки и через 5 сек. новые цены на всех терминалах официантов.
4. Когда создаются товары, им назначается цех: бар или кухня, при окончании заказа, он разбивается и бар печатается на принтере, который помечен как бар, блюда на кухню печатаются на принтере, который стоит на кухне. При добавлении или изменении заказа печатается только разница.
5. Пока нет такой возможности, потому как цифровое меню только в разработке. Планируется к лету.
6. Пока тоже нет возможности. Но тут скорее юридический вопрос. В Украине тут есть свои тонкости, поэтому мы пока решили не добавлять этот функционал.
7. Есть печать логотипа, достаточно загрузить любую картинку в админ-панель.
8. Админ-панель представляет собой обычную админ панель сайта, которая находится на поддомене клиента.
9. Ближе к зиме мы планируем начать разработку открытого API.
10. Сам интерфейс приложения не нативный. Это все html5+css3+js. Мы потратили огромное количество времени чтобы оно выглядело и работало как нативное, потому что даже самые простые анимации из jquery на нем тормозили. Сейчас разницу заметить не возможно. Если интересно — расскажу вкратце как нам это удалось.
"Пользователь может просканировать QR-код с помощью планшета/телефона, открыть меню, и сделать заказ"
Пробемы возникающие если разрешить посетителю использовать свой собственный телефон/планшет:
— ему придется скачать и установить приложение с меню или перейти по ссылке на мобильный сайт ресторана. Во-первых, это занимает время. Во-вторых, не все захотят использовать траффик для скачивания энного количества мегабайт картинок с блюдами.
— какова вероятность, что некий посетитель-приколист выйдет из ресторана и с помощью установленной аппликашки не закажет еще пару стейков и дессерт для столика за которым уже новые посетители? Как вариант, можно для потехи стоять на улице и наблюдая в окно раз за разом вызывать оффицианта к столику с сохраненным qr-кодом.
Я в свое время писал в комментариях про NFC, лично прошлой зимой ездил в метро по мобильнику (фактически, наша компания реализовывает этот проект в технологической части). Пока не буду говорить где, но мы все надеемся, что еще в одном крупном городе будет запущен в полнофункциональном режиме проект оплаты проезда в метро с помощью мобильников с NFC.
Обратите внимание, что ввиду малого количества телефонов с NFC мы применили решение, условно, NFC-SIM.
В симку «зашит» аплет с STK-меню, выбираете вид билета (на 1,5,10 поездок и т. д.), по воздуху происходит запись билета в чип. Т. е. для использования подойдет любой, даже самый дешевый мобильник, а не только дорогой смартфон.
По поводу бизнес-кейса применения NFC — я настроен скептически. Много сказано заманчивых слов, но мало практических решений и модели, как это будет выглядеть.
Например, вот эта фраза «мобильный телефон будет использоваться для чтения RFID меток с уличных досок для объявлений, чтобы на ходу получать информацию о новом суши-баре или сдающейся в аренду однушке».
На каком ходу? Радиус действия Вы сами же указали, до 20 см, причем, извините меня, в отличие от Bluetooth, просто пройти мимо даже на расстоянии 20 см и получить инфу не получится, тут я бы сравнил передачу данных по ИК-приемнику — чуть сдвинул NFC-метку (дрогнула рука), и получение информации может не пройти.
И вообще, что получается, вы должны заранее знать, что хотите получить инфу о суши-баре, подойти к доске, считать инфу на телефон? Еще раз извините, но такая электронная доска курит в сторонке по сравнению с обычной — все равно надо подойти, но простое («устаревшее») чтение обычного текста будет проще и быстрее. Возможно NFC все-таки будет удобнее для записи контактных данных в телефон — не надо бюдеть вручную записывать или сканировать QR-код. Но еще раз, повторюсь, кейс какой-то надуманный, больше для пиара и/или баловства, чем для повсеместного использования (да, знаю, пилоты по этой теме уже есть)
Второй момент «Вы, наверное, знаете о планах введения универсальной карты для жителей России – она будет поддерживать NFC» — снова лукавство. Потому что УЭК поддерживает стандарт бесконтактного интерфейса ISO14443A. Сами же пишете, что «Таким образом, достигается абсолютная совместимость с существующей инфраструктурой бесконтактных карт, которая уже давно используется в наших автобусах, метро и платежных системах.» Т. е. это не УЭК (универсальная электронная карта) будет поддерживать NFC (как Вы пишете), а NFC будет поддерживать существующую инфраструктуру, в т. ч. УЭК.
И вообще, технологически-то да, но не факт, что с помощью NFC-телефона можно будет прочитать информацию с УЭК (разве что, только открытые разделы).
Я, честно говоря, не хотел бы, чтобы в метро любой мог бы считать информацию с моей УЭК с помощью NFC-телефона, и узнать мои ФИО, возраст и, скажем, ИНН. Вроде, ничего страшного, но все же. Думаю, все многие со мной согласятся
Далее «а легкое касание Wi-Fi-роутера – мгновенно настроить смартфон для работы в домашней или офисной беспроводной сети» — это что значит, и пароля вводить не нужно? заходи к нам в офис кто хочешь с Nfc-телефоном, и получай доступ к сети? Ах, пароль нужно будет ввести? тогда принципиальной разницы не вижу — что так, что так вводить.
«Для того чтобы воспроизвести фильм с телефона на большом экране, достаточно будет положить аппарат рядом с телевизором, выбрать нужный контент и включить просмотр через Wi-Fi/UPnP.» — опять не понятно. Зачем тут прослойка в виде NFC?
Все-таки, основное предназначение NFC — это, имхо, быстрая идентификация (микроплатежи, транспорт). Понимаю, что разработчики хотят притянуть за уши и другие «юз кейсы», но пока как-то ненатурально выглядит.
И это, обратите внимание, Стив Джобс как-то не очень жалует NFC — у него пока больше вопросов, чем ответов. А согласитесь, NFC в продукции Apple дала бы толчок к развитию технологии (подняла ее престиж, что ли). понимаю, что Samsung с данным тезисом не согласится, но факт остается фактом.
Я, кстати, писал уже и про AngryBirds с поддержкой NFC — выглядит забавно, но не более, скорее, вызывает некоторое недоумение.
Докину еще несколько ссылок: http://mechanicalmooc.org/ — обертка для курсов OCW, преобразующая их в подобие MOOCов — вам будут присылать письма и напоминать, что нужно посмотреть лекцию или пройти тест; http://www.coursebuffet.com/ — каталог более 700 онлайн-курсов; http://www.eclass.cc/ — мощный поисковик по курсам, в базе 8000+ онлайн-курсов, из них больше 700 — на русском.
Я помню, что рассказывал это много раз, но расскажу еще раз — мне важно не забыть самому за следующие 30 лет.
В институте меня взяли на кафедру работать над диспетчерской системой для железной дороги. Собственно говоря, нас, студентов, поставили делать графику, аспирантка с темой по AI делала экспертную систему, которая бы подсказывала диспетчеру что делать. Для начала делали симулятор, дабы диспетчеры могли учиться рулить движением. К системе надо было прикрутить алгоритм, который бы простраивал картину на некоторое время вперед, зная текущую ситуацию и нас послали к главному гуру советских диспетчерских систем — Завьялову.
Завьялову было, кажется, хорошо за 70. Он жил в большой квартире, а одна из комнат была библиотека. У него было хобби — он переводил американские детективы 30-50-х. Переводил, печатал и ставил на полочки. Кажется, несколько издал, но это не было целью — ему нравилось переводить. Полочки в комнате были до потолка и все забиты переводами.
Мы как-то подружились с ним, он как раз купил PC и учился его программировать. Купил книжку по ассемблеру и MS-DOS … через несколько дней мы увидели, что он хакнул VGA и оно стало показывать какой-то дикий режим типа 48 x 17 — у него было плохое зрение и так было лучше видно. Еще через неделю он спросил нас, где можно купить более подробную книжку про MS-DOS, потому что в этой почему-то нет главы про многозадачность. Мы как смогли объяснили, он удивился и сказал, что не видел ОС без многозадачности с времен машин «Мир», но это не беда… через неделю сообщил, что написал многозадачный монитор, достаточный для его нужд. Он все писал на ассемблере, сказав буквально что ассемблер его удовлетворяет, а учить C он не хочет, потому что может жить ему осталось недолго, не хочется время терять.
Так или иначе он решил написать алгоритм так, чтобы мы его приделали к графической части. Мы валандались две недели, но так и не успели доделать свою часть и приделать к ней нужный интерфейс. А дело шло к какой-то важной демонстрации, и тут Завьялов позвонил и сказал, что у него кое-что готово. Он написал алгоритм. И графическую часть. На ассемблере, за 2 недели, большими буквами (потому что так было лучше ему видно). Один.
Он отдал мне дискету в центре зала м ВДНХ и побежал по своим делам. Я стоял с открытым ртом и с дискетой в руках. Каждый раз, когда мне вдруг начинает казаться, что я очень умный, или что кто-то может быть слишком стар для чего-то, я вспоминаю себя посреди м. ВДНХ и, мне кажется, делаю верные выводы.
Действительно, сольют. Потому что целью комментария кажется именно сбор плюсов, а не желание поделиться информацией.
Почему статья не шлак? Потому что «привлечь внимание к своей персоне», как вы говорите, — это тоже вполне себе сформированная задача. И с этой задачей авторы справились. Чтобы собрать людей вокруг этой темы, продвинуть курсы, свои имена и компанию, не нужно писать действительно хорошие статьи. Достаточно написать чуть лучше среднего по «клинике». После них будут другие статьи, ещё чуть лучше, и так далее. Пока не найдётся тот, кто действительно захочет поделиться информацией об интернет-магазинах вне контекста самопродвижения.
Любые прикладные советы по созданию интернет-магазинов должны основываться на функциональных требований. Которые, в свою очередь, тоже не из пустого места берутся. Чаще всего они нацелены на извлечение максимально возможной прибыли. Но опять же, различия между краткосрочными (срубить денег на товаре, который через две недели потеряет актуальность) и долгосрочными (продажа дешёвого товара, который востребован всегда, но требует для успеха сбора огромной аудитории) стратегиями будут колоссальными.
Чтобы не быть голословным, приведу примеры, процитировав пару предложений из статьи.
«Попав на страницу товара, человек должен получить максимум информации о нем». Если речь пойдёт о китайском телефоне, то к набору информации о нём нужно относиться очень трепетно. То же касается лекарств, не прошедших должных испытаний. Или кредитных товаров. Чем меньше информации выдаётся, тем больше шанс получить клиента.
«На странице категории блок популярных товаров лучше всего располагать в правой колонке, так как левая будет занята фасетным фильтром». Если целевая аудитория магазина — пользователи мобильных устройств, то фильтрацию лучше размещать справа. Особенно, если эта фильтрация динамическая и применяется к списку товаров без перезагрузки страницы. Если разместить её слева, то изменяющийся список товаров в каталоге будет закрыт рукой пользователя. И даже тут мы можем придумать, когда это правило перестаёт действовать (если мы продаём товары для левшей, например). Также, если на сайте с каталогом и фильтрацией существует много другого текстового контента, занимающего лишь одну колонку, то приятней будет, если контентная область не будет скакать на ширину блока фильтрации от страницы к странице.
Что касается самого блока популярных товаров, то его чаще всего нужно располагать в том месте, где покупатель уже закончил с контекстом ознакомления с текущим товаром. Например, внизу страницы.
И, как и в любом примере, я мог бы сам себе возразить, придумав новые возможные контексты.
«На вашем сайте обязательно должна быть возможность подписки на рассылку». Если нам действительно нужно, чтобы народ подписывался, то мы можем… подписывать его по умолчанию, в первом же письме, с сообщением об успешном заказе товара, уведомляя его о том, что он подписан, что мы не спамеры, трепетно относимся к подписчикам и что отписаться можно на такой-то странице.
Опять же, если мы рассчитываем два месяца поторговать ходовым товаром, а потом закрыться, то нам подписка не нужна.
«Адаптивная верстка». Тема холиварная. Лично я придерживаюсь мнения о том, что современные гаджеты спокойно справляются с сайтами и без адаптивных вёрсток. Минусы адаптивной вёрстки:
— Приходится заново знакомиться с интерфейсом, к которому привык на определённом типе устройств;
— Дополнительная напрягающая деятельность по поиску ссылки, ведущей пользователя на полную версию сайта. Ага, попробуйте зайти в свою группу в контакте с мобильного устройства (например, с айпада, у которого разрешение экрана больше, чем у моего настольного компьютера) и переключиться на полную версию. Будете листать ленту, увеличивающуюся «на лету» вниз, пока не дойдёте до подвала. А если попробуете убрать букву «m» в адресе, то при перезагрузке всё равно попадёте в мобильную версию, т.к. она автоматически определится сайтом;
— Существенное удорожание разработки
К чему я это всё? Крутые создатели веб-продуктов мыслят не шаблонными решениями (хотя не хочу умалить их важности! чем больше шаблонов в голове, тем лучше!), а контекстным и функциональным обоснованием любой мелочи в проекте. Поэтому я всегда очень трепетно отношусь к статьям, в которых безо всякой аналитики люди делятся конкретными примерами из своего опыта, описывая контекст, решение и результат.
Мне тоже в свое время очень нравилась эта книга. Но потом я стал сомневаться в некоторых ее тезисах, особенно, наблюдая, что стало с компаниями, которые выбрал Коллинз. А недавно прочел книгу «Эффект Ореола» Розенцвейга (http://www.ozon.ru/context/detail/id/3938570/), и сразу понял, с чем были связаны мои сомнения. Он в своей книге обсуждает и методы работы Коллинза, поэтому советую ее почитать, чтобы составить взвешенное мнение.
Для большинства читателей Хабра, более актуальны книги про компании из списка Fortune 5 000 000. Те кто уже управляют компаниями Fortune 500 — скорее всего не будут ее читать, поэтому — аудитория этой книжки — наивные мечтатели, которые мечтают управлять Microsoft, но сами не способны открыть даже ларька. Присоединюсь к предыдущим ораторам, в макулатуру эту макулатуру. Сейчас стоит начнить с Getting Real и Rework для практики, и Funky Business — для понимания, что старые рецепты не работают в 21 веке.
Баг: code.google.com/p/chromium/issues/detail?id=321879
Пример с вариантов бага + фикса: jsfiddle.net/CKbuD/2/
Библиотека chosen теперь рисует картинку затемнения в выпадающем списке с отступом: harvesthq.github.io/chosen/
Замечено еще с первой бетой.
Имеет много мелких глюков и не имеет бесплатной версии, но для отрисовки responsive сайтов он удобнее, чем GoMockingbird.
Блондинка едет в автомобиле, включает радио и слышит:
— Вы слушаете радио «Европа плюс»!
Она:
— Господи, да откуда они все знают?
Вместо этого
Можно сделать нечто подобное:
Неужели не очевидна избыточность?
если интересует мое личное мнение (в чем я сомневаюсь) — бэм избыточен в своей сложности для 99% проектов. Почему? Да потому что нет необходимости синхронизации отдельных команд. Нет необходимости создания библиотеки общих элементов и проблем с их совместимостью.
БЭМ — это попытка прыгнуть на пять лет вперед, радостно размахивая оперенными трехметровыми костылями
Долетели ли они до цели? Да. Ржут ли над ними? Тоже да.
Потому что единственная и первоочередная задача БЭМа — это инкапсуляция классов. Вот товарищ ниже пишет, как это все появлялось: куча разных команд делала кучу разной хрени, и нужно было их совместить. Когда начали совмещать — ясен хрен что div.mega-link оказался в десяти проектах разом. Поэтому нужно было внедрить префиксы класса. Теоретически можно было бы обойтись .block-name .element-name, но возникала проблема с вложенными блоками: если в родительском блоке и дочернем блоке были .mega-link, понятное дело что к потомку применялись свойства родителя.
Таким образом единственным возможным вариантом было создание классов .block_name__element_name.
Через уже небольшое время народ задолбался от монотонности разумного в общем-то процесса до такой степени, что решил упростить себе жизнь и сделал те самые bem-tools, без которых верстать уже некоторые попросту не умеют.
Вся подстава в том, что в реальности инкапсуляция классов уже существует и работает в Chrome, а с полифиллом (я сам был в шоке, если честно) — и ie10+ и FF, safari etc. Называется решение shadow DOM. По сути — это изолированная часть документа, внутри которой есть собственная логика, скрипты и стили, при этом снаружи повлиять на них практически невозможно. Через пару лет большинство подобных блочных проектов будет разрабатываться именно на базе shadow DOM, а про БЭМ будут помнить только фанатики и на тот момент — старперы, так как объективно он перестанет быть нужен. Это не «дискасс ит», это вполне логичная цепочка заключений: БЭМ создан для того, чтобы решить проблему инкапсуляции стилей, он решает ее, при этом избыточен, имеет определенный порог вхождения, увеличивает размер выходных файлов, через ~3 года 95% браузеров как минимум с полифиллом будут поддерживать технологию, так же решающую эту проблему, но не создающую новых.
Возможно, БЭМ трансформируется во что-то еще, но в текущем состоянии он отомрет. Хотя как промежуточная технология идеологически он хорош.
— Ресурс тех же LED ламп гораздо меньше из за того что умирает «балласт».
— Светодиоды со временем тускнеют, у меня через пару лет лампочки светят раза в полтора менее ярко чем новые.
— Добиться такого же светового потока как при использовании ламп накаливания практически невозможно (либо белит, либо синит, либо желтит)
— При использовании в местах где частые включения/выключения ресурс лампы очень мал — сдыхает балласт.
Сэкономить на использовании этих ламп невозможно, за два года моего эксперимента я портатил на закупку ламп + электроэнергию столько же денег сколько тратил бы на обычные лампы накаливания + потребление.
Не из собственного:
— На изготовление «балласта», светодиода, сборку тратится несоизмеримо больше электроэнергии, чем на изготовление лампы накаливания.
— Производство «балласта», диодов гораздо менее экологическое, чем изготовление лампы накаливания.
— Про утилизацию тоже все замалчивают, если речь идет про люминесцентные лампы, то в них ртуть.
1. Пока нет. Сейчас работаем с Datex'ом, должны закончить работу с ними к февралю. Для этого используем специальный японский преобразователь com to lan. Очень интересный опыт, расскажу о нем обязательно позже. Аналогично собираемся работать с Марией c февраля. 2 эти компании производят практически 85-90% всех фискальных принтеров в Украине. Для России решение будет аналогичным, просто мы чуть позже собираемся на этот рынок.
2. Мобильный эквайринг или обычный эквайринг. В перспективе уйти от физического применения карт и оплачивать счета через мобильный телефон с помощью приложения, к которому привязана карта. Сейчас ведем переговоры с несколькими банками и двумя компаниями, которые это уже делают в Украине.
3. При новой поставке продуктов автоматически пересчитывается все себестоимости блюд с учетом % наценки и через 5 сек. новые цены на всех терминалах официантов.
4. Когда создаются товары, им назначается цех: бар или кухня, при окончании заказа, он разбивается и бар печатается на принтере, который помечен как бар, блюда на кухню печатаются на принтере, который стоит на кухне. При добавлении или изменении заказа печатается только разница.
5. Пока нет такой возможности, потому как цифровое меню только в разработке. Планируется к лету.
6. Пока тоже нет возможности. Но тут скорее юридический вопрос. В Украине тут есть свои тонкости, поэтому мы пока решили не добавлять этот функционал.
7. Есть печать логотипа, достаточно загрузить любую картинку в админ-панель.
8. Админ-панель представляет собой обычную админ панель сайта, которая находится на поддомене клиента.
9. Ближе к зиме мы планируем начать разработку открытого API.
10. Сам интерфейс приложения не нативный. Это все html5+css3+js. Мы потратили огромное количество времени чтобы оно выглядело и работало как нативное, потому что даже самые простые анимации из jquery на нем тормозили. Сейчас разницу заметить не возможно. Если интересно — расскажу вкратце как нам это удалось.
Пробемы возникающие если разрешить посетителю использовать свой собственный телефон/планшет:
— ему придется скачать и установить приложение с меню или перейти по ссылке на мобильный сайт ресторана. Во-первых, это занимает время. Во-вторых, не все захотят использовать траффик для скачивания энного количества мегабайт картинок с блюдами.
— какова вероятность, что некий посетитель-приколист выйдет из ресторана и с помощью установленной аппликашки не закажет еще пару стейков и дессерт для столика за которым уже новые посетители? Как вариант, можно для потехи стоять на улице и наблюдая в окно раз за разом вызывать оффицианта к столику с сохраненным qr-кодом.
Обратите внимание, что ввиду малого количества телефонов с NFC мы применили решение, условно, NFC-SIM.
В симку «зашит» аплет с STK-меню, выбираете вид билета (на 1,5,10 поездок и т. д.), по воздуху происходит запись билета в чип. Т. е. для использования подойдет любой, даже самый дешевый мобильник, а не только дорогой смартфон.
По поводу бизнес-кейса применения NFC — я настроен скептически. Много сказано заманчивых слов, но мало практических решений и модели, как это будет выглядеть.
Например, вот эта фраза «мобильный телефон будет использоваться для чтения RFID меток с уличных досок для объявлений, чтобы на ходу получать информацию о новом суши-баре или сдающейся в аренду однушке».
На каком ходу? Радиус действия Вы сами же указали, до 20 см, причем, извините меня, в отличие от Bluetooth, просто пройти мимо даже на расстоянии 20 см и получить инфу не получится, тут я бы сравнил передачу данных по ИК-приемнику — чуть сдвинул NFC-метку (дрогнула рука), и получение информации может не пройти.
И вообще, что получается, вы должны заранее знать, что хотите получить инфу о суши-баре, подойти к доске, считать инфу на телефон? Еще раз извините, но такая электронная доска курит в сторонке по сравнению с обычной — все равно надо подойти, но простое («устаревшее») чтение обычного текста будет проще и быстрее. Возможно NFC все-таки будет удобнее для записи контактных данных в телефон — не надо бюдеть вручную записывать или сканировать QR-код. Но еще раз, повторюсь, кейс какой-то надуманный, больше для пиара и/или баловства, чем для повсеместного использования (да, знаю, пилоты по этой теме уже есть)
Второй момент «Вы, наверное, знаете о планах введения универсальной карты для жителей России – она будет поддерживать NFC» — снова лукавство. Потому что УЭК поддерживает стандарт бесконтактного интерфейса ISO14443A. Сами же пишете, что «Таким образом, достигается абсолютная совместимость с существующей инфраструктурой бесконтактных карт, которая уже давно используется в наших автобусах, метро и платежных системах.» Т. е. это не УЭК (универсальная электронная карта) будет поддерживать NFC (как Вы пишете), а NFC будет поддерживать существующую инфраструктуру, в т. ч. УЭК.
И вообще, технологически-то да, но не факт, что с помощью NFC-телефона можно будет прочитать информацию с УЭК (разве что, только открытые разделы).
Я, честно говоря, не хотел бы, чтобы в метро любой мог бы считать информацию с моей УЭК с помощью NFC-телефона, и узнать мои ФИО, возраст и, скажем, ИНН. Вроде, ничего страшного, но все же. Думаю,
всемногие со мной согласятсяДалее «а легкое касание Wi-Fi-роутера – мгновенно настроить смартфон для работы в домашней или офисной беспроводной сети» — это что значит, и пароля вводить не нужно? заходи к нам в офис кто хочешь с Nfc-телефоном, и получай доступ к сети? Ах, пароль нужно будет ввести? тогда принципиальной разницы не вижу — что так, что так вводить.
«Для того чтобы воспроизвести фильм с телефона на большом экране, достаточно будет положить аппарат рядом с телевизором, выбрать нужный контент и включить просмотр через Wi-Fi/UPnP.» — опять не понятно. Зачем тут прослойка в виде NFC?
Все-таки, основное предназначение NFC — это, имхо, быстрая идентификация (микроплатежи, транспорт). Понимаю, что разработчики хотят притянуть за уши и другие «юз кейсы», но пока как-то ненатурально выглядит.
И это, обратите внимание, Стив Джобс как-то не очень жалует NFC — у него пока больше вопросов, чем ответов. А согласитесь, NFC в продукции Apple дала бы толчок к развитию технологии (подняла ее престиж, что ли). понимаю, что Samsung с данным тезисом не согласится, но факт остается фактом.
Я, кстати, писал уже и про AngryBirds с поддержкой NFC — выглядит забавно, но не более, скорее, вызывает некоторое недоумение.
В институте меня взяли на кафедру работать над диспетчерской системой для железной дороги. Собственно говоря, нас, студентов, поставили делать графику, аспирантка с темой по AI делала экспертную систему, которая бы подсказывала диспетчеру что делать. Для начала делали симулятор, дабы диспетчеры могли учиться рулить движением. К системе надо было прикрутить алгоритм, который бы простраивал картину на некоторое время вперед, зная текущую ситуацию и нас послали к главному гуру советских диспетчерских систем — Завьялову.
Завьялову было, кажется, хорошо за 70. Он жил в большой квартире, а одна из комнат была библиотека. У него было хобби — он переводил американские детективы 30-50-х. Переводил, печатал и ставил на полочки. Кажется, несколько издал, но это не было целью — ему нравилось переводить. Полочки в комнате были до потолка и все забиты переводами.
Мы как-то подружились с ним, он как раз купил PC и учился его программировать. Купил книжку по ассемблеру и MS-DOS … через несколько дней мы увидели, что он хакнул VGA и оно стало показывать какой-то дикий режим типа 48 x 17 — у него было плохое зрение и так было лучше видно. Еще через неделю он спросил нас, где можно купить более подробную книжку про MS-DOS, потому что в этой почему-то нет главы про многозадачность. Мы как смогли объяснили, он удивился и сказал, что не видел ОС без многозадачности с времен машин «Мир», но это не беда… через неделю сообщил, что написал многозадачный монитор, достаточный для его нужд. Он все писал на ассемблере, сказав буквально что ассемблер его удовлетворяет, а учить C он не хочет, потому что может жить ему осталось недолго, не хочется время терять.
Так или иначе он решил написать алгоритм так, чтобы мы его приделали к графической части. Мы валандались две недели, но так и не успели доделать свою часть и приделать к ней нужный интерфейс. А дело шло к какой-то важной демонстрации, и тут Завьялов позвонил и сказал, что у него кое-что готово. Он написал алгоритм. И графическую часть. На ассемблере, за 2 недели, большими буквами (потому что так было лучше ему видно). Один.
Он отдал мне дискету в центре зала м ВДНХ и побежал по своим делам. Я стоял с открытым ртом и с дискетой в руках. Каждый раз, когда мне вдруг начинает казаться, что я очень умный, или что кто-то может быть слишком стар для чего-то, я вспоминаю себя посреди м. ВДНХ и, мне кажется, делаю верные выводы.
urbansheep.livejournal.com/880783.html
Почему статья не шлак? Потому что «привлечь внимание к своей персоне», как вы говорите, — это тоже вполне себе сформированная задача. И с этой задачей авторы справились. Чтобы собрать людей вокруг этой темы, продвинуть курсы, свои имена и компанию, не нужно писать действительно хорошие статьи. Достаточно написать чуть лучше среднего по «клинике». После них будут другие статьи, ещё чуть лучше, и так далее. Пока не найдётся тот, кто действительно захочет поделиться информацией об интернет-магазинах вне контекста самопродвижения.
Любые прикладные советы по созданию интернет-магазинов должны основываться на функциональных требований. Которые, в свою очередь, тоже не из пустого места берутся. Чаще всего они нацелены на извлечение максимально возможной прибыли. Но опять же, различия между краткосрочными (срубить денег на товаре, который через две недели потеряет актуальность) и долгосрочными (продажа дешёвого товара, который востребован всегда, но требует для успеха сбора огромной аудитории) стратегиями будут колоссальными.
Чтобы не быть голословным, приведу примеры, процитировав пару предложений из статьи.
«Попав на страницу товара, человек должен получить максимум информации о нем». Если речь пойдёт о китайском телефоне, то к набору информации о нём нужно относиться очень трепетно. То же касается лекарств, не прошедших должных испытаний. Или кредитных товаров. Чем меньше информации выдаётся, тем больше шанс получить клиента.
«На странице категории блок популярных товаров лучше всего располагать в правой колонке, так как левая будет занята фасетным фильтром». Если целевая аудитория магазина — пользователи мобильных устройств, то фильтрацию лучше размещать справа. Особенно, если эта фильтрация динамическая и применяется к списку товаров без перезагрузки страницы. Если разместить её слева, то изменяющийся список товаров в каталоге будет закрыт рукой пользователя. И даже тут мы можем придумать, когда это правило перестаёт действовать (если мы продаём товары для левшей, например). Также, если на сайте с каталогом и фильтрацией существует много другого текстового контента, занимающего лишь одну колонку, то приятней будет, если контентная область не будет скакать на ширину блока фильтрации от страницы к странице.
Что касается самого блока популярных товаров, то его чаще всего нужно располагать в том месте, где покупатель уже закончил с контекстом ознакомления с текущим товаром. Например, внизу страницы.
И, как и в любом примере, я мог бы сам себе возразить, придумав новые возможные контексты.
«На вашем сайте обязательно должна быть возможность подписки на рассылку». Если нам действительно нужно, чтобы народ подписывался, то мы можем… подписывать его по умолчанию, в первом же письме, с сообщением об успешном заказе товара, уведомляя его о том, что он подписан, что мы не спамеры, трепетно относимся к подписчикам и что отписаться можно на такой-то странице.
Опять же, если мы рассчитываем два месяца поторговать ходовым товаром, а потом закрыться, то нам подписка не нужна.
«Адаптивная верстка». Тема холиварная. Лично я придерживаюсь мнения о том, что современные гаджеты спокойно справляются с сайтами и без адаптивных вёрсток. Минусы адаптивной вёрстки:
— Приходится заново знакомиться с интерфейсом, к которому привык на определённом типе устройств;
— Дополнительная напрягающая деятельность по поиску ссылки, ведущей пользователя на полную версию сайта. Ага, попробуйте зайти в свою группу в контакте с мобильного устройства (например, с айпада, у которого разрешение экрана больше, чем у моего настольного компьютера) и переключиться на полную версию. Будете листать ленту, увеличивающуюся «на лету» вниз, пока не дойдёте до подвала. А если попробуете убрать букву «m» в адресе, то при перезагрузке всё равно попадёте в мобильную версию, т.к. она автоматически определится сайтом;
— Существенное удорожание разработки
К чему я это всё? Крутые создатели веб-продуктов мыслят не шаблонными решениями (хотя не хочу умалить их важности! чем больше шаблонов в голове, тем лучше!), а контекстным и функциональным обоснованием любой мелочи в проекте. Поэтому я всегда очень трепетно отношусь к статьям, в которых безо всякой аналитики люди делятся конкретными примерами из своего опыта, описывая контекст, решение и результат.