Usability *

Чек-аут

В интерфейсах интернет-магазинов это экран, который пользователь видит перед тем, как перейти на страницу оплаты.

Это то место, где он уже принял решение о покупке, и указывает последние необходимые параметры для заключения сделки.

Можно найти много чек-листов о том, как оформлять чек-ауты. Я же здесь озвучу самое главное:

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

— Здесь уже не нужно основное меню навигации, ведь в нём есть ссылки, по которым пользователь может кликнуть и уйти со страницы куда-то ещё. Поэтому шапку можно смело убирать;
— Подвал тоже;
— Не стоит просить заполнить больше данных, чем нужно для оформления сделки. Если есть какие-то необязательные поля, то они, скорее всего, навредят;
— Кнопка с призывом к действию должна быть только одна и с ней ничего не должно визуально конкурировать.

Я бы предположил, что это всё и так очевидно, однако сам начал убирать шапки с подвалами со страниц чек-аутов года два-три назад. А ведь, казалось бы, опытный специалист.

Вообще подобные страницы уже давно спроектированы и оттестированы в любом крупном маркетплейсе и как две капли воды похожи друг на друга.

В продолжение моего поста от 20.12.2023... Да, я до сих пор пытался продолжать пользоваться Evernote... Но сегодня понял, что:

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

• меня достало постоянное напоминание каждый день об очередном обновлении (и ладно бы хотя бы ушла ошибка синхронизации — нет, обновляется каждый день. а что‑то полезное не появляется)

• из всего Evernote я по факту пользуюсь WebClipper, потому что из‑за ошибок синхронизации и тормознутости десктопный клиент почти бесполезен (особенно, когда что‑то нужно найти)

• оказалось, что и веб‑клиент Evernote теперь жутко тормозит даже просто чтобы вывести список заметок

Ну и понял, что уже все совсем созрело для перехода на Obsidian...
И что же ? Перейти можно сейчас только через десктоп-версию (потому что загрузить в Obsidian можно через enex-файл, а он выгружается только из десктопа Evernote). Т.е. новые заметки, созданные за последний месяц, нужно переносить "ручками".

В общем ладно - запустил я выгрузку из десктоп-версии в enex... и думаю - проверю, а место у меня хватит ? Иду в папку с данными evernote, и вижу, что она занимает 20ГБ (думаю - ничего так я за 10+ лет насобирал)... потом погружаюсь внутрь и понимаю, что сама база занимает ~5ГБ, а остальные ~14ГБ - это папка с копиями установочных пакетов (см. скрин ниже)... В общем адьос Evernote - десктоп удаляю!

Приходит потенциальный клиент к разработчику…

— Мне бы сайт разработать! Можете сказать, сколько это будет стоить?
— А проектная документация у вас есть?
— Не-а.
— Она нужна для оценки. Попробуйте сходить к проектировщику интерфейсов. Возвращайтесь с проектной документацией — и я оценю разработку.

И клиент идёт к проектировщику интерфейсов. Например, ко мне.

— Мне бы сайт спроектировать! Можете сказать, сколько это будет стоить?
— А задание на проектирование у вас есть?
— Не-а. Только не говорите, что опять надо к кому-то идти?!
— Нет. Давайте с вами созвонимся такого-то числа во столько-то — и я за час соберу у вас все необходимые сведения для составления этого задания. Дальше вы проверите, нигде ли я не ошибся — и если всё ок, то я смогу оценить проектирование.

Вот примерно так я обычно и создаю документы под названием «Функциональные требования» (ФТ). По ним я могу оценить объём работ по проектированию. Вот вам видеоролик, в котором показываю пример такого документа и рассказываю о некоторых нюансах его подготовки.

Q-OTP - двухфакторная аутентификация на VueJS.

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

Компонент подключается как Quasar App Extension:

quasar ext add q-otp

Пример подключения:

<template>
  <QOtp
      field-classes="q-ml-xs q-mr-xs"
      @complete="(code) => alert(code)"
  />
</template>
<script lang="ts" setup>
  import QOtp from 'quasar-app-extension-q-otp'
</script>

Исходный код доступен на Гитхаб под лицензией MIT.

Этот ляп в последнем обновлении Evernote сегодня "сделал мой день"...

Программа долго что-то делала после обновления, как обычно обещая, что "осталось 2 минуты"

Через полчаса мне надоело ждать - нажал "крестик"... И вид окна мгновенно изменился:

собственно дальше программа продолжила "висеть", но уже обещая, что "закроется" через "1 минуту 15 секунд".

К ее чести можно сказать, что в итоге она все-таки завершила прерывание за примерно 10 минут :-)

Как документ назовёшь…

…так его потом и найдёшь!

Один из этапов моей работы — составление документа с функциональными требованиями к проекту. И поначалу я их называл примерно так: «Функциональные требования к приложению Нэмо». Храню я их в гугл.доках и в отдельных папках на своём компе.

Через какое-то время я понял, что функциональные требования в заголовке можно сократить до «ФТ». Более короткие названия лучше умещались во вьюпортах и в них было проще ориентироваться: «ФТ к приложению Нэмо».

Ещё через какое-то время документов поднакопилось и я стал всё чаще по ним искать, когда нужно было продемонстрировать новому клиенту что-то из своего портфолио. Я не держал в голове все названия проектов, поэтому мне было проще всего отфильтровать список по слову ФТ — и пробежаться по нему глазами.

Но с моим подходом все названия начинались на «ФТ». От этого было мало толку. Я сделал правильные выводы и с того момента называю документы так: «Нэмо, ФТ». Здесь не осталось ничего лишнего, название проекта на первом месте, а также есть атрибут, по которому можно отфильтровать список. Например, у функциональных спецификаций атрибут «ФС».