>>конструкцией «Всего 18322, по… на страницу»
Может ее всю вниз тогда? Просто она иначе не вяжется с цепочкой действий «просмотрел — пролистал»: когда наступает время листать, она оказывается уже где-то наверху.
>>ключевиками, это наиболее быстро и просто
А никто ж не спорит )) Помнится, у фотолии (? вроде) было так — apple, juice, orientation/portrait, people/no people, fitness. Метаинформация на коленке, да )
>>вынести этот поиск прямо в инпут
В общем, надо как-то недвусмысленно указывать, что работает дополнительный отбор, которого нет в тексте строки. Хотя бы в сообщении «не найдено» его упоминать (вообще просто должно быть).
(все еще по поиску)
— убрать нафиг номера фото и кол-во закачек. Я бы вообще сделал поверх превьюшки два мелкопиксельных контрола — «звезда» и цифру популярности, и показывал только при наведении. И место экономится, и удобнее, и не отвлекает.
По просмотру и закачке
— показать похожие, по максимально точному набору ключевиков (мелко в сторонке в столбик, например)
— причесать оверлей закачки фото. «Начинается закачка..», ссылку эту монструозную заменить на что-то повменяемее (напр., тайтл фото)
— если считается траф — показывать, хотя бы примерно, остаток в сессии; иначе получается, что сервис «внезапно вырубается». По исчерпанию трафа, опять же, внятно об этом говорить.
В общем
— оверлей регистрации, после принятия данных, сразу закрывается. На долю секунды, можно заметить, там появляется какое-то красное уведомление. В результате о том, что нужно ждать письма на мыло, узнаешь из этого самого письма. Надо подправить.
— во вложенных страницах размер шапки по вертикали можно безболезненно урезать вдвое. Зачем тратить место, которое можно занять фото?
— в базе много однотипных фото, явно с одной фотосессии. Если придумаете способ их удобно кластеризовать (возможность индивидуально исключать конкретные из поиска) — будет вам респект.
— например, я пишу «cake», но блины (pancake) мне не нужны. Способ?
Навигатор, поиск
— выбор количества фото в выдаче надо продублировать внизу около страничной навигации. Не сразу находится. Ну и опции 150, 200 тоже не лишние.
— если есть квадратик «следующая страница», то можно и по клику аяксом подтягивать следующий кусок выборки прямо вместо него. См. гетти.
— где быстрая выборка? В больших выдачах фотки смотришь со скоростью 3-5шт/сек, надо или favourites, или лайтбокс-корзинку, или еще что. Обязательно в один клик (т.е. js, видимо)
— расширенный поиск. Если будет с подстановкой категорий (которых, как я понимаю, нет) — будет круто.
— собственно категории. Хотя бы потому, что у фото кроме объекта есть еще технические параметры (цвет фона, orientation, люди) — раз, во-вторых — чтобы отделить реальные категории (apple, juice) от абстрактных (fitness, joy).
— рандомная выдача везде по дефолту. Иначе будет «эффект рабмлера», когда популярные фото болтаются в топе вечно.
— при активации поиска по цвету — надо выносить его ближе к контексту поиска (т.е. в левую часть строки), выделять, подсвечивать, прописывать и всячески свистеть. Потому что иначе последующие запросы будут «не работать» по непонятной причине (фото по цвету нет).
Алексей, а есть ли какие-то ограничения на использование сервиса, если не пользоваться готовым плагином?
Т.е., если брать с хоста /updates/update.txt, скажем, два раза в неделю, и присоединять к уже существующему на сторонней системе спамовому стоп-листу — результат вроде как достигается, никакого лишнего шума. Или есть ограничения?
Может ее всю вниз тогда? Просто она иначе не вяжется с цепочкой действий «просмотрел — пролистал»: когда наступает время листать, она оказывается уже где-то наверху.
>>ключевиками, это наиболее быстро и просто
А никто ж не спорит )) Помнится, у фотолии (? вроде) было так — apple, juice, orientation/portrait, people/no people, fitness. Метаинформация на коленке, да )
>>вынести этот поиск прямо в инпут
В общем, надо как-то недвусмысленно указывать, что работает дополнительный отбор, которого нет в тексте строки. Хотя бы в сообщении «не найдено» его упоминать (вообще просто должно быть).
— убрать нафиг номера фото и кол-во закачек. Я бы вообще сделал поверх превьюшки два мелкопиксельных контрола — «звезда» и цифру популярности, и показывал только при наведении. И место экономится, и удобнее, и не отвлекает.
По просмотру и закачке
— показать похожие, по максимально точному набору ключевиков (мелко в сторонке в столбик, например)
— причесать оверлей закачки фото. «Начинается закачка..», ссылку эту монструозную заменить на что-то повменяемее (напр., тайтл фото)
— если считается траф — показывать, хотя бы примерно, остаток в сессии; иначе получается, что сервис «внезапно вырубается». По исчерпанию трафа, опять же, внятно об этом говорить.
В общем
— оверлей регистрации, после принятия данных, сразу закрывается. На долю секунды, можно заметить, там появляется какое-то красное уведомление. В результате о том, что нужно ждать письма на мыло, узнаешь из этого самого письма. Надо подправить.
— во вложенных страницах размер шапки по вертикали можно безболезненно урезать вдвое. Зачем тратить место, которое можно занять фото?
— в базе много однотипных фото, явно с одной фотосессии. Если придумаете способ их удобно кластеризовать (возможность индивидуально исключать конкретные из поиска) — будет вам респект.
— например, я пишу «cake», но блины (pancake) мне не нужны. Способ?
Может, еще что-то добавлю ;)
Спасибо вам за сервис!
Навигатор, поиск
— выбор количества фото в выдаче надо продублировать внизу около страничной навигации. Не сразу находится. Ну и опции 150, 200 тоже не лишние.
— если есть квадратик «следующая страница», то можно и по клику аяксом подтягивать следующий кусок выборки прямо вместо него. См. гетти.
— где быстрая выборка? В больших выдачах фотки смотришь со скоростью 3-5шт/сек, надо или favourites, или лайтбокс-корзинку, или еще что. Обязательно в один клик (т.е. js, видимо)
— расширенный поиск. Если будет с подстановкой категорий (которых, как я понимаю, нет) — будет круто.
— собственно категории. Хотя бы потому, что у фото кроме объекта есть еще технические параметры (цвет фона, orientation, люди) — раз, во-вторых — чтобы отделить реальные категории (apple, juice) от абстрактных (fitness, joy).
— рандомная выдача везде по дефолту. Иначе будет «эффект рабмлера», когда популярные фото болтаются в топе вечно.
— при активации поиска по цвету — надо выносить его ближе к контексту поиска (т.е. в левую часть строки), выделять, подсвечивать, прописывать и всячески свистеть. Потому что иначе последующие запросы будут «не работать» по непонятной причине (фото по цвету нет).
Сейчас еще накидаю.
Есть технические и недоработки, и «недодумки».
Критику примете, или уже поздно пить боржоми?
Согласно CSS2:
>>low resolution, color, limited-scrollability screens, sound available
Забавно получается, в целом ))
D))
Похоже, горячий финский парень делал этот концепт просто _под себя_.
* и не видно, кстати, что же такого революционного он предложил в развесовке, особенно с учетом нижнего ряда клавиш.
Т.е., если брать с хоста /updates/update.txt, скажем, два раза в неделю, и присоединять к уже существующему на сторонней системе спамовому стоп-листу — результат вроде как достигается, никакого лишнего шума. Или есть ограничения?