Pull to refresh
71
0
Александр @Bright

User

Send message
Небольшое уточнение по поводу скидок.

Есть такое условие:
20% after 12 months of uninterrupted payments and 40% after 24 months of uninterrupted payments are available for both monthly and yearly plans

И такое:
Active (or expired recently) upgrade subscription holders get 2 first years of subscription for the price of 1.


Верно ли это:
1. Есть текущая подписка на один продукт по старой модели
2. До окончания старой подписки покупаем продление на год по новой модели, получаем два года
3. После двух лет получаем скидку 40% на продление продукта или подписку на другие продукты

Если верно – то это очень круто =)
И да, у любого сервиса/инструмента по подписке должна быть кнопка «да-да, я всё знаю, но вот сейчас надо запуститься и работать». Доступная для тех, у кого подписка была/есть, но внезапно кончилась или по какой-то причине не может быть проверена.
prigara, gorohoroh, а в чём смысл оставлять разделение на новых и старых пользователей при подписке? Почему это разделение было для «вечных» лицензий – понятно, но при подписке нет особой разницы платит пользователь первый год или второй, главное – платит. Думаю, выше вы уже оценили сколько недопонимания возникает из-за этого.

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

Я предлагаю примерно такой вариант:
Один продукт – полная цена подписки ($50 – 150$ в год).
Второй и последующие – со скидкой 25-30% (логично, если новая политика направлена на тех, кому надо несколько продуктов)
Надо больше продуктов – вот Toolbox за 149$ год (для тех, кому иметь один продукт + несколько со скидкой уже не выгодно)
Ещё «прекрасный» пример — ввод данных банковской карты при оплате дом.ру.

Кто-то решил, что первым полем должно быть имя и фамилия, а не номер карты как в большинстве подобных форм и как на самой карте.

Беда в том, что форма ввода данных карты — штука более-менее привычная и заполнять её пытаешься уже на автомате, не читая подписи в полям. Лично я только с третьего раза сообразил почему форма ругается на невалидные данные.
Кстати, на Android, например, долгое нажатие выводит подсказку для конкретного действия.

Когда я узнал об этой фиче, то наконец-то смог выяснить назначение некоторых иконок в Feedly =)
Тогда да, Bower не нужен. Как вы сами отметили, фронтенд бывает разный, для каких-то проектов достаточно одного HTML-файла с парой-тройкой ссылок на CDN, а для каких-то и Bower не помешает.
Ага, и для мобилок не будет никакой разницы — т.к. title там не виден.

Суть в чём — люди явно тратят дополнительное время на перевод заголовков. Добавляет ли это ценности дайджесту? Сомнительно. Ибо перевод не всегда очевидно даёт понять о чём была речь в оригинальном заголовке + статьи всё равно остаются на английском, языковой барьер это никак не снимает.
Собственно, управление зависимостями. Вы можете в bower.json указать конкретные версии библиотек от которых зависит ваше приложение. Можете даже указать конкретный коммит в GIT-репозитории (иногда бывает нужно и такое, когда, например, в какой-то из веток/пулл-реквестов есть фикс, но автор либы не спешит выпускать новую версию).

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

В проект приходит новый разработчик — bower install и у него есть всё.

Собираем версию на продакшен — bower install, получили сборку с нужными зависимостям.

И да, если нужный вам пакет (bootstrap, например) зависит от другого (jquery в случае с бутстрапом), то Bower автоматически скачает зависимости.

Да, всё это будет не нужно, если вы будете ходить по сайтам, качать нужные версии и хранить их в репозитории. Но и обновление версий, и разрешение зависимостей — всё надо делать вручную. А это, в общем-то, довольно примитивная и нудная задача с которой лучше всего справляются машины.
var gulp = require('gulp'),
    watch = require('gulp-watch'),
    prefixer = require('gulp-autoprefixer'),
    uglify = require('gulp-uglify'),
    cssmin = require('gulp-cssmin'),
    sass = require('gulp-sass'),
    sourcemaps = require('gulp-sourcemaps'),
    rigger = require('gulp-rigger'),
    imagemin = require('gulp-imagemin'),
    pngquant = require('imagemin-pngquant'),
    rimraf = require('rimraf'),
    connect = require('gulp-connect'),
    opn = require('opn');


Ещё рекомендую gulp-load-plugins. Тогда весь код выше заменяется строчкой:

var plugins = require('gulp-load-plugins')();


Соответственно плагины будут доступны как plugins.autoprefixer, plugins.sass и т.д.
Удивительно, почти в два раз больше человек проголосовало за перевод. Поэтому аргументирую почему перевод заголовков не нужен:

1) Это рождает подобные конструкции:
Приступая к работе с грубо проработанными скетчами вайрфреймов

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

2) Нет смысла переводить заголовки, если за ссылкой всё равно контент на английском

3) Процитирую комментарий olegafx из его дайджеста:
В 99% всё на английском. Если что-то есть на русском, то само название ссылки это подскажет :)

Либо же переводить названия, но добавлять флажок. Вот только зачем…

То бишь, можно будет убрать флажок.
Стоит ещё заглянуть в комментарии к оригинальной статье, там разработчики из фэйсбука отвечают на некоторые вопросы:
blog.andrewray.me/flux-for-stupid-people/#comment-1819956843
Фиксится минут за пять.
Раз до сих пор не сделали — похоже, что это «фирменный стиль» =)
Само собой, статьи на тему «почему не ангуляр» нужны. Но эта статья какая-то странная… Здесь скорее перечислены проблемы, возникающие при старте, чем какие-то фатальные недостатки, которые будут преследовать вас на протяжении всего процесса разработки.

Собственно, из недавно прочитанного я бы посоветовал это:
www.fse.guru/2-years-with-angular
www.fse.guru/why-you-should-learn-angular-anyway
Стоит отметить, что статья довольно качественная.
По поводу юникод-гамбургера: есть прекрасный сайт unicode.johnholtripley.co.uk/ с подробной информацией о поддержке юникода в разных браузерах.

И там советуют:
Using the 3 horizontal line 'burger' icon for your navigation? Use 2261 (≡) (96%) instead of 2630 (☰) (58%)
Спасибо за ответ.

Объясню почему у меня вообще возник такой вопрос: повсюду можно встретить рекомендации снижать количество загружаемых картинок и скриптов. Сам гугл утверждает, что скорость загрузки сайта — важный фактор в ранжировании. У вас же по-прежнему используются картинки там, где можно применять CSS-градиент и скрипты грузятся отдельными файлами. Конечно, это изменение отработанного процесса, но польза от такого, имхо, очевидна.

Второй момент сложнее — адаптивность. Но если у вас одна сетка, то вполне можно сделать так, чтобы сайты можно было просматривать на телефонах.

Возможно я слишком однобоко смотрю на ваш процесс, только с технической стороны, но мне кажется, что в конечном итоге ваши клиенты только выиграют от таких изменений.
Посмотрел сейчас пару проектов из портфолио и возникли вопросы:
1) Предполагается ли в вашей системе развитие базы/шаблонов, по которым вы строите типовые решения? Как вы интегрируете это свой процесс?
2) Как удаётся привлекать и удерживать людей в условиях такой шаблонной работы?

P.S: оценивал субъективно и с точки зрения фронтенда/вёрстки.
Ох. Эти ваши убеждения тут на хабре видят новички. Кто-то ведь даже скопирует ваш код и будет использовать у себя.

У меня к вам большая просьба — смотрите на то, как реализуют ваши советы другие.

Например, чекбокс, скрытый с помощью display: none будет недоступен для перехода Tab'ом. Поэтому на wtfforms.com и в других демках чекбоксы скрывают прозрачностью или иными способами.
Добавьте внутрь span сразу после input, для него и пишите стили. Пример тут: wtfforms.com/

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Date of birth
Registered
Activity