Переодически приходят заказы на разработку настольных приложений, и каждый раз я смотрю на разработку UI как баран на новые ворота. В основном из-за непонимания как эффективно разделять модель и представление. Какие хорошие книги или серии статей есть на эту тему?
C>Переодически приходят заказы на разработку настольных приложений, и каждый раз я смотрю на разработку UI как баран на новые ворота. В основном из-за непонимания как эффективно разделять модель и представление. Какие хорошие книги или серии статей есть на эту тему?
UI разрабатывается на основе функция, которые пользователь делает в системе.
Поэтому рекомендую прочитать книгу Алистера Коберна: https://www.labirint.ru/books/421003/
Сильно прояснится.
Книжка небольшая, но очень информативная.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, cppguard, Вы писали:
C>Переодически приходят заказы на разработку настольных приложений, и каждый раз я смотрю на разработку UI как баран на новые ворота. В основном из-за непонимания как эффективно разделять модель и представление. Какие хорошие книги или серии статей есть на эту тему?
Это же зависит от того на чем вы пишете UI. Вообще есть два самых распространенных паттерна MVC и MVVM. А так я бы смотрел документацию и примеры по либе с помощью которой ведется разработка.
Здравствуйте, BlackEric, Вы писали:
BE>Это же зависит от того на чем вы пишете UI.
А если в задачу входит и выбор средств реализации UI тоже?
BE>Вообще есть два самых распространенных паттерна MVC и MVVM. А так я бы смотрел документацию и примеры по либе с помощью которой ведется разработка.
Подозреваю, что вопрос ТС был понят не до конца. У меня вот тоже всегда была такая же (в плане выбора визуальных средств для представления модели) проблема с UI. Например, модель включает несколько параметров, которые могут быть включены/выключены. Обычно такое делается чекбоксами или двумя списками (все и выбранные). Когда параметров два-три, и нагляднее, и удобнее сделать чекбоксы. Когда пятьдесят — списки. А когда их восемь, десять, двенадцать? Надо ж еще как-то учесть предпочтения пользователей, а они могут быть сильно разными.
Здравствуйте, LaptevVV, Вы писали:
LVV>прочитать книгу Алистера Коберна LVV>Сильно прояснится.
Пролистал ее по диагонали — по-моему, она переусложнена. То, что там подробно расписывается и разжевывается, чаще всего само становится понятным после определения задач и способов взаимодействия. А способы взаимодействия — это уже больше изобретательство.
Например, в метро разных стран еще много лет назад можно было купить жетоны или разовые билеты, заплатив картой, и совершенствовалась именно такая система оплаты. Лишь недавно появились турникеты, к которым можно приложить карту непосредственно. Казалось бы, элементарно — но ведь не допер никто раньше.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Подозреваю, что вопрос ТС был понят не до конца. У меня вот тоже всегда была такая же (в плане выбора визуальных средств для представления модели) проблема с UI. Например, модель включает несколько параметров, которые могут быть включены/выключены. Обычно такое делается чекбоксами или двумя списками (все и выбранные). Когда параметров два-три, и нагляднее, и удобнее сделать чекбоксы. Когда пятьдесят — списки. А когда их восемь, десять, двенадцать? Надо ж еще как-то учесть предпочтения пользователей, а они могут быть сильно разными.
Как например, помещаются на экране — чекбоксы, не помещаются — списки.
Чётное количество — радость перфекциониста.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Например, в метро разных стран еще много лет назад можно было купить жетоны или разовые билеты, заплатив картой, и совершенствовалась именно такая система оплаты. Лишь недавно появились турникеты, к которым можно приложить карту непосредственно. Казалось бы, элементарно — но ведь не допер никто раньше.
Метро транспорт бедных.
Карта перестала быть роскошью.
Утрата карты (украли-отжали) и утрата жетона. Есть разница.
Здравствуйте, akasoft, Вы писали:
A>Как например, помещаются на экране — чекбоксы, не помещаются — списки.
На каком экране? Они бывают и 1024x600 (до сих пор), и 12K. Кому-то нравится большое количество чекбоксов в развесистом диалоге, поскольку все сразу видно и под рукой, а кому-то подавай диалог покомпактнее, и тогда — только списки. Как понять заранее, каких больше?
Здравствуйте, cppguard, Вы писали:
C>Переодически приходят заказы на разработку настольных приложений, и каждый раз я смотрю на разработку UI как баран на новые ворота. В основном из-за непонимания как эффективно разделять модель и представление. Какие хорошие книги или серии статей есть на эту тему?
Ставишь Lazarus и пишешь всю бизнес-логику как реакцию на события кнопок и прочих элементов интерфейса, "модель" хранишь как часть полей форм, т.е. "вида". Заморачиваться MVC и прочим имеет смысл только для сложных приложений.
Здравствуйте, akasoft, Вы писали:
A>Метро транспорт бедных.
Вы там давно были? Посмотрите, кто там ездит в часы пик — удивитесь. И не только в московском, и не только в России.
A>Карта перестала быть роскошью. A>Утрата карты (украли-отжали) и утрата жетона. Есть разница.
Не вижу разницы. Зачем к автоматам, продающим жетоны/билеты, картоприемники приделали еще лет двадцать назад, а к турникетам — совсем недавно? Бесконтактные карты тут ни при чем — списывать мелкие суммы без PIN-кода можно было и тогда.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Подозреваю, что вопрос ТС был понят не до конца. У меня вот тоже всегда была такая же (в плане выбора визуальных средств для представления модели) проблема с UI. Например, модель включает несколько параметров, которые могут быть включены/выключены. Обычно такое делается чекбоксами или двумя списками (все и выбранные). Когда параметров два-три, и нагляднее, и удобнее сделать чекбоксы. Когда пятьдесят — списки. А когда их восемь, десять, двенадцать? Надо ж еще как-то учесть предпочтения пользователей, а они могут быть сильно разными.
Всё верно. Проблема не закодить сам UI, а выполнить взаимодействие пользовательского интерфейса с моделью так, чтобы потом не было больно расширять приложение. Последение пару раз я отказывался от UI вообще и программировал DSL, благо, что заказчики радостно соглашались.
Здравствуйте, gyraboo, Вы писали:
G>Здравствуйте, cppguard, Вы писали:
C>>Переодически приходят заказы на разработку настольных приложений, и каждый раз я смотрю на разработку UI как баран на новые ворота. В основном из-за непонимания как эффективно разделять модель и представление. Какие хорошие книги или серии статей есть на эту тему?
G>Ставишь Lazarus и пишешь всю бизнес-логику как реакцию на события кнопок и прочих элементов интерфейса, "модель" хранишь как часть полей форм, т.е. "вида". Заморачиваться MVC и прочим имеет смысл только для сложных приложений.
И это предлагает человек, который ставит процессы разработки в различных конторах?
Здравствуйте, BlackEric, Вы писали:
C>>>Переодически приходят заказы на разработку настольных приложений, и каждый раз я смотрю на разработку UI как баран на новые ворота. В основном из-за непонимания как эффективно разделять модель и представление. Какие хорошие книги или серии статей есть на эту тему?
G>>Ставишь Lazarus и пишешь всю бизнес-логику как реакцию на события кнопок и прочих элементов интерфейса, "модель" хранишь как часть полей форм, т.е. "вида". Заморачиваться MVC и прочим имеет смысл только для сложных приложений.
BE>И это предлагает человек, который ставит процессы разработки в различных конторах?
Ну да, если разрабатывать "по уму по MVC", то дороже выйдет. MVC весьма усложняет разработку и сам код, и требует от людей определенной квалификации, которую не всегда найдешь среди суппортеров. А простецкий "дельфийский" подход к клепанию GUI весьма дешев и эффективен, он начинает давать сбой только для сложных ГУИ-шных проектов.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>На каком экране?
На том, на котором будут показаны. ЕМ> Кому-то нравится большое количество чекбоксов в развесистом диалоге, поскольку все сразу видно и под рукой, а кому-то подавай диалог покомпактнее, и тогда — только списки.
Восприятие разнится от человека к человеку. Всем не угодить. ЕМ>Как понять заранее, каких больше?
Спросить. Или предположить.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Вы там давно были? Посмотрите, кто там ездит в часы пик — удивитесь. И не только в московском, и не только в России.
Вот поэтому карта и перестала быть роскошью. Мультипаспорт.
ЕМ>Не вижу разницы.
Раньше была разница, украли у тебя карту или жетон на метро. Карта была роскошью.
ЕМ> Зачем к автоматам, продающим жетоны/билеты, картоприемники приделали еще лет двадцать назад, а к турникетам — совсем недавно?
Не позволяли доступные технологии и консерватизм владельцев бизнеса. "Работает — не трогай" во всей красе.
Здравствуйте, akasoft, Вы писали:
A>Раньше была разница, украли у тебя карту или жетон на метро.
В чем была разница? Я вижу разницу только в сроках выпуска новой карты (пара недель двадцать лет назад, один-два — сейчас).
A>Карта была роскошью.
В 90-х карта была роскошью только в развивающихся странах (в России тоже). Уже в самом начале 2000-х карты выпускали десятки банков, они были доступны всем желающим, тогда же начали перечислять туда зарплаты. Другое дело, что в России до середины 2000-х было особо некуда совать те карты, кроме банкоматов, но в США и Западной Европе торговых точек, принимавших карты, было до хренища и в 90-е.
A>Не позволяли доступные технологии и консерватизм владельцев бизнеса. "Работает — не трогай" во всей красе.
Технологии как раз были доступны — просто никто не думал, что это может иметь значительный спрос.
Здравствуйте, cppguard, Вы писали:
C>Переодически приходят заказы на разработку настольных приложений, и каждый раз я смотрю на разработку UI как баран на новые ворота. В основном из-за непонимания как эффективно разделять модель и представление. Какие хорошие книги или серии статей есть на эту тему?
Начни с About Face https://www.amazon.com/About-Face-Essentials-Interaction-Design/dp/1118766571
Иначе начнешь делать с модели и получишь не самый лучший интерфейс.
Здравствуйте, cppguard, Вы писали:
C>Переодически приходят заказы на разработку настольных приложений, и каждый раз я смотрю на разработку UI как баран на новые ворота. В основном из-за непонимания как эффективно разделять модель и представление. Какие хорошие книги или серии статей есть на эту тему?
Создай класс-фасад с методами-бизнес логики: добавить то-то, удалить то-то, посчитать то-то. В общем, то, что делает твое приложение.
Методы этого класса — это контракт между моделью и представлением. Для выполнения любых операций представление должно работает только с этим классом и ни с чем больше.
Представление может быть реализовано как угодно — создавай любые классы — для окон, для настроек, и т.п.
Реализация бизнес-логики тоже как угодно — создавай классы для алгоритмов, бизнес-объектов, файлов, внешних сервисов и т.п.
Если возникают сомнения, является ли что-то бизнес-логикой (должно быть в модели) или логикой представления (должно быть в представлении), то представь сразу что ты в дальнейшем разработаешь другие интерфейсы, кроме графического будет текстовый, голосовой и т.п. Если поведение одинаковое для всех видов интерфейсов — это бизнес-логика, если отличается — это представление.
Здравствуйте, Буравчик, Вы писали:
C>>Переодически приходят заказы на разработку настольных приложений, и каждый раз я смотрю на разработку UI как баран на новые ворота. В основном из-за непонимания как эффективно разделять модель и представление. Какие хорошие книги или серии статей есть на эту тему?
Б>Создай класс-фасад с методами-бизнес логики: добавить то-то, удалить то-то, посчитать то-то. В общем, то, что делает твое приложение.
Б>Методы этого класса — это контракт между моделью и представлением. Для выполнения любых операций представление должно работает только с этим классом и ни с чем больше.
Б>Представление может быть реализовано как угодно — создавай любые классы — для окон, для настроек, и т.п. Б>Реализация бизнес-логики тоже как угодно — создавай классы для алгоритмов, бизнес-объектов, файлов, внешних сервисов и т.п.
Б>Если возникают сомнения, является ли что-то бизнес-логикой (должно быть в модели) или логикой представления (должно быть в представлении), то представь сразу что ты в дальнейшем разработаешь другие интерфейсы, кроме графического будет текстовый, голосовой и т.п. Если поведение одинаковое для всех видов интерфейсов — это бизнес-логика, если отличается — это представление.
Спасибо, но это прям какие-то основы промышленного проектирования. Когда взаимосвязи видно невооружённым глазом, то и проблем-то нет, а вот когда начинаются всякие циклические зависимости или неизбежно протекающие абстракции, то становится грустно.
Здравствуйте, akasoft, Вы писали:
ЕМ>>В чем была разница? A>В непредоставлении услуги и потраченном держателем карты времени и нервах.
Я все равно не понимаю, о чем Вы. Можете вместо отрывочных полунамеков выдать мало-мальски развернутое описание ситуации утраты карты сейчас и в начале 2000-х?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Например, в метро разных стран еще много лет назад можно было купить жетоны или разовые билеты, заплатив картой, и совершенствовалась именно такая система оплаты. Лишь недавно появились турникеты, к которым можно приложить карту непосредственно. Казалось бы, элементарно — но ведь не допер никто раньше.
Доперли давно, это очевидное решение: я о таком мечтал когда первую бесконтактную карту получил, а я не самый умный на планете, и карта у меня была не самая первая. Наверняка были какие-то другие причины, почему сразу не сделали.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, cppguard, Вы писали:
C>В основном из-за непонимания как эффективно разделять модель и представление.
Что в этом сложного? Представь, что у тебя два представления одновременно: интерфейс командной строки и графический интерфейс. Чтобы обеспечить функциональную эквивалентность при таких требованиях, тебе просто придётся эффективно изолировать модель от представления.
Выше упомянули Алистера Кокберна, у него (и многих других, но идея его) есть описание такого способа проектирования программных систем: гексагональная архитектура.
V>Что в этом сложного? Сложность в том, что некоторые сущности или события требуют изменений и модели, и представления, и непонятно, где и как их проектировать. Например, в Java Swing есть JTextArea. На первый взгляд это представление. Но внутри есть Document, а это уже модель. Казалось бы — храни модель отдельно и загружай через JTextArea::setDocument, только вот "родной" метод JTextArea::read, во-первых, при чтении делает много побочной работы, которую придётся копировать, если хранить модель отдельно, а во-вторых, пересоздаёт модель заново (класс модели — иммутабелен), что влечёт за собой ручное пересоздание всяких listeners. Может, конечно, сама Swing ущербна, только вот при работе с Qt у меня были аналогичные вопросы.
V>Выше упомянули Алистера Кокберна, у него (и многих других, но идея его) есть описание такого способа проектирования программных систем: гексагональная архитектура.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Не вижу разницы. Зачем к автоматам, продающим жетоны/билеты, картоприемники приделали еще лет двадцать назад, а к турникетам — совсем недавно? Бесконтактные карты тут ни при чем — списывать мелкие суммы без PIN-кода можно было и тогда.
В Питере что-то не видел таких автоматов (в смысле, с картами, да ещё 20 лет назад). Вроде несколько лет тока как появились. Недавно как-то попробовал, кстати, воспользоваться — он так безбожно тупит
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Другое дело, что в России до середины 2000-х было особо некуда совать те карты, кроме банкоматов, но в США и Западной Европе торговых точек, принимавших карты, было до хренища и в 90-е.
Это особенно удивительно, если учесть, что в Европе и сейчас легко можно найти места, где не расплатится картой, а в РФ это уже разряда вон выходящего. А в штатах, говорят, до сих пор могут под копирку откатать (хз, как это называется)
Здравствуйте, ути-пути, Вы писали:
УП>Доперли давно, это очевидное решение: я о таком мечтал когда первую бесконтактную карту получил, а я не самый умный на планете, и карта у меня была не самая первая. Наверняка были какие-то другие причины, почему сразу не сделали.
А я чо-то очкую. Плюс у меня пяток карт — нужно доставать именно нужную, а то хз, откуда спишется. Риск потерять, или кто-то стырит — повышается. А проездным хлопнул и готово. И карты можно с собой не таскать, я так часто делаю, кстати.
Здравствуйте, удусекшл, Вы писали:
У>А я чо-то очкую. Плюс у меня пяток карт — нужно доставать именно нужную, а то хз, откуда спишется.
Не, не спишется вообще. Он при коллизиях дает отлуп.
У>Риск потерять, или кто-то стырит — повышается. А проездным хлопнул и готово. И карты можно с собой не таскать, я так часто делаю, кстати.
Телефон-то таскаешь? Вот его вместо карт.
У проездного другое преимущество — по нему дешевле. Карты же хороши, когда ездишь на ОТ в год по обещанию, как я.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, ути-пути, Вы писали:
У>>А я чо-то очкую. Плюс у меня пяток карт — нужно доставать именно нужную, а то хз, откуда спишется.
УП>Не, не спишется вообще. Он при коллизиях дает отлуп.
Значит, всё равно доставать карты, искать нужную
У>>Риск потерять, или кто-то стырит — повышается. А проездным хлопнул и готово. И карты можно с собой не таскать, я так часто делаю, кстати.
УП>Телефон-то таскаешь? Вот его вместо карт.
Платить им гораздо менее удобно, чем картами. Пока приложение откроешь, пока выберешь карту. Отпечаток (не всегда срабатывает), или пин вводить надо. Плюс на кассах часто не срабатывает — пока со всех сторон терминала не помашешь, бывает, что и не сработает. Хз, может, в метро лучше. В наземном транспорте — у меня в трамваях по моему маршруту — стабильно не работает, в тролейбусах/автобусах — через раз. И бывает, что показывает не зеленый кружок или красный крест, а желтый кружок — не помню, это вроде типа уже оплачено. В общем, пока тут не слишком всё удобно с телефона.
УП>У проездного другое преимущество — по нему дешевле. Карты же хороши, когда ездишь на ОТ в год по обещанию, как я.
А я привык немного мелочи носить — ну, как мелочи — 100/200/500 бумажек несколько. Удобно, если терминал сломался где, ну и вообще, немного денег наликом бывает полезно. Для метро раз в редко затариваю сколько-то жетонов, и если пару запасных уже истратил — кладу из кучки в кармашек
Здравствуйте, удусекшл, Вы писали:
У>А я привык немного мелочи носить — ну, как мелочи — 100/200/500 бумажек несколько. Удобно, если терминал сломался где, ну и вообще, немного денег наликом бывает полезно. Для метро раз в редко затариваю сколько-то жетонов, и если пару запасных уже истратил — кладу из кучки в кармашек
У нас давно нет жетонов. Для разовых поездок все равно карточки. В кармашек для мелочи не положишь.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, ути-пути, Вы писали:
У>>А я привык немного мелочи носить — ну, как мелочи — 100/200/500 бумажек несколько. Удобно, если терминал сломался где, ну и вообще, немного денег наликом бывает полезно. Для метро раз в редко затариваю сколько-то жетонов, и если пару запасных уже истратил — кладу из кучки в кармашек
УП>У нас давно нет жетонов. Для разовых поездок все равно карточки. В кармашек для мелочи не положишь.
Здравствуйте, cppguard, Вы писали:
C>Переодически приходят заказы на разработку настольных приложений, и каждый раз я смотрю на разработку UI как баран на новые ворота. В основном из-за непонимания как эффективно разделять модель и представление. Какие хорошие книги или серии статей есть на эту тему?
А где ищете такие заказы? Или где они вас сами находят?
Здравствуйте, удусекшл, Вы писали:
У>Это особенно удивительно, если учесть, что в Европе и сейчас легко можно найти места, где не расплатится картой, а в РФ это уже разряда вон выходящего. А в штатах, говорят, до сих пор могут под копирку откатать (хз, как это называется)
Слип это называется. Но думаю, такие места еще поискать надо. Вряд ли сегодня много магазинов там, где нет хотя бы плохонького инета.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, удусекшл, Вы писали:
У>Это особенно удивительно, если учесть, что в Европе и сейчас легко можно найти места, где не расплатится картой, а в РФ это уже разряда вон выходящего. А в штатах, говорят, до сих пор могут под копирку откатать (хз, как это называется)
Я в США проехал по всем 50 штатам, и слип видел только один раз — в туристическом бюро в Африке.
Здравствуйте, cppguard, Вы писали:
C>Здравствуйте, Vladek, Вы писали:
V>>Что в этом сложного? C>Сложность в том, что некоторые сущности или события требуют изменений и модели, и представления, и непонятно, где и как их проектировать. Например, в Java Swing есть JTextArea. На первый взгляд это представление. Но внутри есть Document, а это уже модель. Казалось бы — храни модель отдельно и загружай через JTextArea::setDocument, только вот "родной" метод JTextArea::read, во-первых, при чтении делает много побочной работы, которую придётся копировать, если хранить модель отдельно, а во-вторых, пересоздаёт модель заново (класс модели — иммутабелен), что влечёт за собой ручное пересоздание всяких listeners. Может, конечно, сама Swing ущербна, только вот при работе с Qt у меня были аналогичные вопросы.
Для тебя это всё представление. Модель — это твой код, который моделирует бизнес-процессы, которые тебе собственно надо автоматизировать. Код, который будет использовать и настраивать JTextArea, так же является частью представления — это код знает, как взять твою модель и преобразовать её в Document. Твоя модель от этого никак не зависит, а вот представление зависит от модели. Это правильная изоляция компонентов системы и буква D в SOLID.
Здравствуйте, ути-пути, Вы писали:
У>>Это особенно удивительно, если учесть, что в Европе и сейчас легко можно найти места, где не расплатится картой, а в РФ это уже разряда вон выходящего. А в штатах, говорят, до сих пор могут под копирку откатать (хз, как это называется)
УП>Слип это называется. Но думаю, такие места еще поискать надо. Вряд ли сегодня много магазинов там, где нет хотя бы плохонького инета.
Мне в Европе несколько лет назад откатали. Реальный слип, с чернилами и роликом. Я прям офигел. В деревне, в гостинице (Франция, если не ошибаюсь). Первый раз узнал почему цифры на карточке выпуклые, то есть в чем идея
Здравствуйте, cppguard, Вы писали:
C>Переодически приходят заказы на разработку настольных приложений, и каждый раз я смотрю на разработку UI как баран на новые ворота. В основном из-за непонимания как эффективно разделять модель и представление. Какие хорошие книги или серии статей есть на эту тему?
По дизайну у Темы Лебедева в их магазинусе хорошая подборка книг. В топе "психбольница" Купера или "интерфейс" Раскина например.
Мне кажется что разделение модели и представления это не самое важное при разработке UI (пользователей это вообще не волнует, я думаю)
Здравствуйте, bnk, Вы писали:
bnk>Мне в Европе несколько лет назад откатали. Реальный слип, с чернилами и роликом. Я прям офигел. В деревне, в гостинице (Франция, если не ошибаюсь). Первый раз узнал почему цифры на карточке выпуклые, то есть в чем идея
Там что, даже сотового инета не было? Непаханное поле для кардеров...
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Зачем к автоматам, продающим жетоны/билеты, картоприемники приделали еще лет двадцать назад, а к турникетам — совсем недавно?
Это где так? У нас они совсем недавно появились, а лет 20 назад типичное использование карты заключалось исключительно в снятии налички в банкомате.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, bnk, Вы писали:
bnk>Мне в Европе несколько лет назад откатали. Реальный слип, с чернилами и роликом. Я прям офигел. В деревне, в гостинице (Франция, если не ошибаюсь).
Франция — она такая. Там еще до сих пор активно используются чеки. Я пару лет назад пытался арендовать грузовичок в одной сети гипермаркетов — плату за аренду они списали с карты, а депозит потребовали чеком. Поскольку чековой книжки у меня тогда не было, аренда не состоялась. Списанную с карты сумму они вернули тоже чеком.
Здравствуйте, ути-пути, Вы писали:
УП>лет 20 назад типичное использование карты заключалось исключительно в снятии налички в банкомате.
В крупных/дорогих магазинах, казино и подобных местах карты принимались еще в 90-х. А в первой половине 2000-х пошло активное внедрение повсеместно. Понятно, что до касс в супермаркетах дошло не сразу.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>В крупных/дорогих магазинах, казино и подобных местах карты принимались еще в 90-х. А в первой половине 2000-х пошло активное внедрение повсеместно. Понятно, что до касс в супермаркетах дошло не сразу.
Вот автоматы, принимающие оплату картами, я впервые увидел гораздо позже, чем терминалы на кассах. И это были уже скорее 10-е годы.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Посмотрите, кто там ездит в часы пик — удивитесь. И не только в московском, и не только в России.
