Comments 34
Думаю, что имеет смысл:
писать заголовок в фоме, включающий название сущности (для группы - наверное это будет перечень),
для отдельных сущностей выводить процент накопления в дропдауне,
сделать одну кнопку вместо двух
писать заголовок в фоме, включающий название сущности (для группы - наверное это будет перечень),
для отдельных сущностей выводить процент накопления в дропдауне,
сделать одну кнопку вместо двух
не вижу смысл писать название. строка, содержащая название и так связана с формой.
процент накопления.. а разве сейчас он не в дропдауне?
делать перевод и менять константу одновременно, по идее, не надо. не вижу смысла вешать на одну кнопку. помоему вариант с двумя кнопками очевиднее.
в любом случае, сейчас речь не об этом. не будем вдаваться в детали формы. дайайте воспринимать ее просто как "какую-то форме". интересней привязка этой формы к записям.
процент накопления.. а разве сейчас он не в дропдауне?
делать перевод и менять константу одновременно, по идее, не надо. не вижу смысла вешать на одну кнопку. помоему вариант с двумя кнопками очевиднее.
в любом случае, сейчас речь не об этом. не будем вдаваться в детали формы. дайайте воспринимать ее просто как "какую-то форме". интересней привязка этой формы к записям.
Мне кажется не стоит двигать форму редактирования, пусть только выделение строки происходит.
а если сущностей будет тыща штук ?
не совсем понятно, как позиционировать форму при групповом выделение. тоесть, если первый выделенный элемент находится вне пределов видимой области. по идее, надо оставлять ее всегда в пределах видимости.
Думаю чел должен понимать что выбирает, групповой признак выборки будет у него в мозгу.
допустим список на две страницы. я выделил первый элемент, потом проскролал вниз и выделил последний. теперь, что-бы сделать какое-то действие, мне надо венуться в начало страницы, к первой записи. как вариант, привязать форму к первой выделенной записи, но, при этом, когда запись уходит за пределы видимости окна, форма должна оставаться в пределах окна.
position:fixed в DOM-браузерах или expressions в IE.
из очевидных улучшений:
1) добавить возможность выбора всех сущностей;
2) заменить текстовые проценты в таблице на текст-бокс, чтобы позволить изменять значение не выделяя пункт;
3) делать выбранные более четкими, а не наоборот(понимаю, что рука дрогнула, но всё-же).
4)операции над одной сущностью очень неудобны - тяжело провести мышью прямую от названия до блока операции. гораздо правильнее будет выделять полоску при клике. когда ничего не выбрано в поле операций лучше дизайблить контролы, а не прятать блок целиком.
1) добавить возможность выбора всех сущностей;
2) заменить текстовые проценты в таблице на текст-бокс, чтобы позволить изменять значение не выделяя пункт;
3) делать выбранные более четкими, а не наоборот(понимаю, что рука дрогнула, но всё-же).
4)операции над одной сущностью очень неудобны - тяжело провести мышью прямую от названия до блока операции. гораздо правильнее будет выделять полоску при клике. когда ничего не выбрано в поле операций лучше дизайблить контролы, а не прятать блок целиком.
Думаю будет лучше, если в пункте 2) сделать не текст-бокс, а комбо с градацией - 5 10 25 50 75 100
1. само-собой
2. изначально задумывалось сделать выпадайки, но меня смущает эта батарея. если использовать боксы, то как подтверждать изменение?
3. не совсем понял, но тем не мение, это просто набросок, не имеющей связи с реальностью :)
4. я думал об этом, но идея с кликом мне не очень нравится. совсем не очевидное действие. разве-что иконку редактирования добавлять.
2. изначально задумывалось сделать выпадайки, но меня смущает эта батарея. если использовать боксы, то как подтверждать изменение?
3. не совсем понял, но тем не мение, это просто набросок, не имеющей связи с реальностью :)
4. я думал об этом, но идея с кликом мне не очень нравится. совсем не очевидное действие. разве-что иконку редактирования добавлять.
2)подтверждение можно запрашивать либо в одном месте для всей таблицы кнопкой "сохранить все изменения"(лучший вариант), либо при снятии фокуса с текстбокса(менее прозрачный).
4)отметить чекбокс нажатием на текст рядом с ним не является очевидным действием?
4)отметить чекбокс нажатием на текст рядом с ним не является очевидным действием?
2. при снятии фокуса однозначно не вариант. общая кнопка тоже не очень хорошо. если я сделал 10 изменений, а потом где-то ошибся, то я либо сохраняю все изменения, вместе с ошибкой, либо теряю 10 корректных изменений, отказавшись от сохранения.
4. тоесть что-бы совершить операцию над записью, надо выделить чекбокс, а потом, что-бы работать с другой, снять этот чекбокс?
4. тоесть что-бы совершить операцию над записью, надо выделить чекбокс, а потом, что-бы работать с другой, снять этот чекбокс?
2) если вы знаете, где ошиблись, то без труда найдёте и исправите, в противном случае вам поможет только откат по версиям(undo/redo). здесь и пригодится сохранение при снятии фокуса.
4) заменив справа две кнопки одной, можно снимать чекбокс по сабмиту. что вполне логично т.к. при нажатии на сабмит обычно происходит перезагрузка страницы и снятие чекбоксов.
5) 2 кнопки вместо одной
4) заменив справа две кнопки одной, можно снимать чекбокс по сабмиту. что вполне логично т.к. при нажатии на сабмит обычно происходит перезагрузка страницы и снятие чекбоксов.
5) 2 кнопки вместо одной
Как я понял в первом случае пользователю нужно провести курсор горизонтально вдоль строки, чтобы добраться до формы - задача довольно проблематичная (горизонтально двигать курсор довольно сложно).
Изменение процента можно сделать так - при наведнии на строчку текст со значением процента заменяется на поле (с таким же значением). Если пользователь его меняет, то в конце строки появляется кнопки "Сохранить" и "Отменить". Или можно использовать одну кнопку "Сохранить" для всей таблицы.
Изменение процента можно сделать так - при наведнии на строчку текст со значением процента заменяется на поле (с таким же значением). Если пользователь его меняет, то в конце строки появляется кнопки "Сохранить" и "Отменить". Или можно использовать одну кнопку "Сохранить" для всей таблицы.
Для изменения счетов - значение также заменяется полем. Возможны два варианта:
1. Вводится новое значение суммы на счете. Если оно больше того, которое сейчас, то второй счет уменьшается на такое же значение. Если меньше - увеличивается.
2. Вводится, например, "+100" или "-200". Этот вариант будет работать, если на счете не может быть отрицательных сумм.
1. Вводится новое значение суммы на счете. Если оно больше того, которое сейчас, то второй счет уменьшается на такое же значение. Если меньше - увеличивается.
2. Вводится, например, "+100" или "-200". Этот вариант будет работать, если на счете не может быть отрицательных сумм.
С точки зрения решения "академической" задачи - интересное решение.
Но что меня всегда смущало в таких статьях - отсутствие упоминания контекста, пользователей и предполагаемых проблем которые должен решить новый интерфейс.
Но что меня всегда смущало в таких статьях - отсутствие упоминания контекста, пользователей и предполагаемых проблем которые должен решить новый интерфейс.
1. Не двигайте форму. И не прячьте. Пусть она будет всегда видна. Можете задисейблить ее, если ничего не выделено. Даже текст добавить: "выберите что-нибудь слева в конце концов".
2. Если записей будет много, скролльте "тело" таблицы. Заголовки и форма недвижимы. Высоту тела можете высчитывать по высоте "окна браузера" или просто зафиксить.
3. Если записей будет много, пишите где-нибудь: "вы уже навыделяли 16 штук записей".
2. Если записей будет много, скролльте "тело" таблицы. Заголовки и форма недвижимы. Высоту тела можете высчитывать по высоте "окна браузера" или просто зафиксить.
3. Если записей будет много, пишите где-нибудь: "вы уже навыделяли 16 штук записей".
Subj я считаю вообще основной проблемой интерфейсного юзабилити. Универсального решения до сих пор нет. Всегда частные.
Вы должны описать сценарии пользователей при работе с данным объектом и контекст их работы. Иначе все вышеперечисленные предложения это гадание на кофейной гуще.
Ваше решение имеет массу проблем, например:
1. С виду совершенно невозможно определить, что имеется возможность выбора одного элемента
2. Тем более не определить, что можно выполнять групповые операции.
3. Опять же видя изначальный вариант таблицы у меня нет никаких "визуальных улик", что можно вообще что-то с эти делать, а не просто просматривать.
4. Операции как они реализованы оптимизированы не для того, чтобы "увидев, быстро поняв, выполнить что-то с полной уверенностью, что я сделаю то, что мне надо". Нет, они оптимизированы под "быстрое совершение многочисленных, рутинных операция хорошо натренированной операционисткой", но при этом не используя самого быстрого способа, а именно с помощью клавиатуры. Так какой у вас случай?
1. С виду совершенно невозможно определить, что имеется возможность выбора одного элемента
2. Тем более не определить, что можно выполнять групповые операции.
3. Опять же видя изначальный вариант таблицы у меня нет никаких "визуальных улик", что можно вообще что-то с эти делать, а не просто просматривать.
4. Операции как они реализованы оптимизированы не для того, чтобы "увидев, быстро поняв, выполнить что-то с полной уверенностью, что я сделаю то, что мне надо". Нет, они оптимизированы под "быстрое совершение многочисленных, рутинных операция хорошо натренированной операционисткой", но при этом не используя самого быстрого способа, а именно с помощью клавиатуры. Так какой у вас случай?
Sign up to leave a comment.
Операции над отдельными элементами списка и группами. Реальная задача…