Калькулятор 1.0β
May. 12th, 2010 05:34 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
ermouthЯ тут для корпосайта написал калькулятор – онлайн-считалку всяких журнальчегов-буклетегов.
Интерфейсег вышел на славу:
Делалось это всё так:
Сначала я посидел погонял над сценариями использования – и решил, что все вкусности типа ссылки на расчёт, код для блога и подобную хрень я пока имплементить не стану, да и думать над этим особо не буду. То-есть, надо было быстро нарисовать простой интерфейс, в котором в минимум кликов можно что-то посчитать и погонять варианты.
Это значит, что считать надо на клиенте, а не на сервере – чтобы перезагрузок страницы не было и не мудрить с джейсонами всякими (кто знает, поймёт).
Потом в моём любимом корелдрове нарисовался макет интерфейса, меня в общем то первая же итерация и устроила:
Потом я это всё располосовал на составные части (это фрагмент есичё, там длинная портянка):
Потом прикинул, как передавать данные для расчётов на клиента, первая итерация выглядела примерно так:
Тут есть ещё важный вопрос – как не передавая таблицу с ценами обеспечивать точность расчёта при разных параметрах – количество страниц, тираж, уровень дизайна могут меняться, и очевидно, что их надо расчитывать на месте.
Это несложно потому что ценообразование в полиграфии и издательских делах – как правило линейная функция со смещением. Это вот что значит.
Предположим, вы запросили у типографии цены на печать журналов объёмом 32 и 64 страницы, тиражом 500 и 1500 экз. И получили в ответ 4 цены.
Оказывается, этих данных достаточно, чтобы с очень хорошим приближением считать другие объёмы и тиражи самому. Скажем, чтобы посчитать, сколько будет стоить журнал объёмом 48 страниц тиражом 1000 экз, не надо писать в типографию ещё раз – достаточно простой линейной интерполяции по двум переменным.
Это значит, что на клиента в считалке мне достаточно передавать 4 цены при двух разных тиражах и двух разных объёмах, остальное посчитается на месте по простой формуле:
p11+(x-x1)*(p12-p11)/(x2-x1))*(1-(y-y1)/(y2-y1))+(p21+(x-x1)*(p22-p21)/(x2-x1))*(1-(y2-y)/(y2-y1))
)))))
На деле всё немножко сложнее, но несильно – возни с интерфейсом куда больше. Интерфейс выжрал прилично времени – процентов 80, наверное. Получилось 12 килобайт жабаскрипта, особо не оптимизировал, лень -- не те цифры )
Потом нарисовались картинки – и вуаля, получилась считалка. Пока там не весь ассортимент, но со временем будет весь.
Также попозже появятся ссылки на расчёт, автоматическая синхронизация с нашей интранетной расчётной системой (пока ручками всё делается) и возможность откопипэйстить расчёт по-человечьи (пока никуда не годно копипэйстится).
Заметим, кстати, что проверка правильности введённых значений, предупреждения и пересчёт таблицы с ценами делаются риалтайм, кнопки “Пересчитать” нет в принципе )
Ругайте, есичё. Бета там, хули.
И да, на сайтеге корпоративном ссылка открывающая калькулятор – в левом нижнем углу сайтега, штоп в глаза не лез пока.
Интерфейсег вышел на славу:
Делалось это всё так:
Сначала я посидел погонял над сценариями использования – и решил, что все вкусности типа ссылки на расчёт, код для блога и подобную хрень я пока имплементить не стану, да и думать над этим особо не буду. То-есть, надо было быстро нарисовать простой интерфейс, в котором в минимум кликов можно что-то посчитать и погонять варианты.
Это значит, что считать надо на клиенте, а не на сервере – чтобы перезагрузок страницы не было и не мудрить с джейсонами всякими (кто знает, поймёт).
Потом в моём любимом корелдрове нарисовался макет интерфейса, меня в общем то первая же итерация и устроила:
Потом я это всё располосовал на составные части (это фрагмент есичё, там длинная портянка):
Потом прикинул, как передавать данные для расчётов на клиента, первая итерация выглядела примерно так:
Тут есть ещё важный вопрос – как не передавая таблицу с ценами обеспечивать точность расчёта при разных параметрах – количество страниц, тираж, уровень дизайна могут меняться, и очевидно, что их надо расчитывать на месте.
Это несложно потому что ценообразование в полиграфии и издательских делах – как правило линейная функция со смещением. Это вот что значит.
Предположим, вы запросили у типографии цены на печать журналов объёмом 32 и 64 страницы, тиражом 500 и 1500 экз. И получили в ответ 4 цены.
Оказывается, этих данных достаточно, чтобы с очень хорошим приближением считать другие объёмы и тиражи самому. Скажем, чтобы посчитать, сколько будет стоить журнал объёмом 48 страниц тиражом 1000 экз, не надо писать в типографию ещё раз – достаточно простой линейной интерполяции по двум переменным.
Это значит, что на клиента в считалке мне достаточно передавать 4 цены при двух разных тиражах и двух разных объёмах, остальное посчитается на месте по простой формуле:
p11+(x-x1)*(p12-p11)/(x2-x1))*(1-(y-y1)/(y2-y1))+(p21+(x-x1)*(p22-p21)/(x2-x1))*(1-(y2-y)/(y2-y1))
)))))
На деле всё немножко сложнее, но несильно – возни с интерфейсом куда больше. Интерфейс выжрал прилично времени – процентов 80, наверное. Получилось 12 килобайт жабаскрипта, особо не оптимизировал, лень -- не те цифры )
Потом нарисовались картинки – и вуаля, получилась считалка. Пока там не весь ассортимент, но со временем будет весь.
Также попозже появятся ссылки на расчёт, автоматическая синхронизация с нашей интранетной расчётной системой (пока ручками всё делается) и возможность откопипэйстить расчёт по-человечьи (пока никуда не годно копипэйстится).
Заметим, кстати, что проверка правильности введённых значений, предупреждения и пересчёт таблицы с ценами делаются риалтайм, кнопки “Пересчитать” нет в принципе )
Ругайте, есичё. Бета там, хули.
И да, на сайтеге корпоративном ссылка открывающая калькулятор – в левом нижнем углу сайтега, штоп в глаза не лез пока.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2010-05-12 01:39 am (UTC)no subject
Date: 2010-05-12 01:41 am (UTC)no subject
Date: 2010-05-13 12:20 pm (UTC)надеюсь уже просто увидимся в скором времени и без поводов )
no subject
Date: 2010-05-12 05:26 am (UTC)Functional баг:
Вводишь количество страниц 15 (текстом вводишь, без кнопочек). Числа обновляются. Наивный посетитель думает, что видит цифры для 15 страниц, а на самом деле он видит цифры для 12 (что будет понятно, если нажать Tab).
Proposed solution #1: Задизейбли text box.
Proposed solution #2: Разреши шаг в 1 страницу для расчётов, но оставь дельту 4 для кнопок (caveat: если не делится на 4, то кнопка должна будет сначала прыгать на ближайшее число, делящееся на 4, а потом уже прибавлять по 4).
2.
Usability баг.
"Тираж, экз" и "Объём, стр" совершенно друг под другом. Создаётся впечатление, что левая колонка - это тираж.
Proposed solution #1: Добавь пару перед тиражом.
Proposed solution #2: Добавь разделительную линию по диагонали
Proposed solution #3: Разбей ячейку на 4, и раскидай эти два текста по углам.
В остальном - красиво, уютно.
no subject
Date: 2010-05-12 08:19 pm (UTC)2. сначала были стрелочки -- они даже на макете есть -- но потом я их выкинул, решив что всё и так понятно. тут я ещё подумаю, как сделать.
no subject
Date: 2010-05-12 10:12 am (UTC)no subject
Date: 2010-05-12 10:29 am (UTC)no subject
Date: 2010-05-12 10:29 am (UTC)no subject
Date: 2010-05-12 10:35 am (UTC)no subject
Date: 2010-05-12 10:36 am (UTC)я согласна и на роль жены, я же говорила