Идеи UI для того, когда панели инструментов перестали работать

При использовании JDK 6 затем, Вы могли бы хотеть проверить Примечание ConcurrentHashMap

putIfAbsent метод в том классе.

8
задан 3 revs, 2 users 100% 3 July 2011 в 04:35
поделиться

10 ответов

You're well out of the comfort zone, through the discomfort zone, and halfway through the having-a-hot-poker-shoved-up-your-backside zone :-)

You should really be thinking of the toolbar as a speed-bar, somewhere where the user can go to do common operations with minimal actions. Other than the Gimp with its infamous UI, I can't fathom any application that would need anywhere near 1,000 common operations worthy of use in a speed-bar.

Perhaps you need to rethink what you're providing.

Some of the Microsoft applications do it reasonably well, they divide their toolbars into sections (e.g., drawing, statistics, formatting) and let the user decide which sections are shown. That way the user decides if they want a minimal workspace or whether they want the whole top half of their workspace taken up by toolbars.

The non-common operations should always be available by menus anyway, whether common is fixed by you (hard-coded), chosen by the user (configuring those sections) or "intelligently" shown by the program (based on previous use).

Here's what I would consider a good approach.

  1. Have all operations accessible from the menus by dividing them into sections (operations within a section should be at least vaguely related). Let's assume for now you can have 30 sections of 30 operations each (unlikely, I know, but simple for this discussion).

  2. Have a special section for adaptive operations. By that, I mean a section the program will populate with operations based on how often the user uses them. To do that, you need to keep a record of how many times an operation is used by the user (each user has their own count, of course, since their usage profile will be different).

  3. Allow the user to configure which sections are displayed in toolbars, including the adaptive one. This gives them control over it.

  4. The adaptive section should be populated by the most commonly used operation provided they don't already appear in another toolbar already. That way, the user can get at the most commonly used operations which aren't already on one of their chosen toolbars.

That seems to me the most flexible solution, giving the user total control over the use of their screen real-estate.

8
ответ дан 3 November 2019 в 14:19
поделиться

I'd think the biggest question here is "what kind of interaction flow are your typical users looking for?" Take a look at how your users actually interact with your program as it stands - are there certain patterns in how they access the various items you have on toolbars?

For instance, are some of your toolbar items extremely frequently used, while others are rarely accessed and when they are, typically accessed along with other similar functions? Perhaps the former items belong on the toolbar, while the latter items would be better suited to some kind of set of palettes that could be opened in a sidebar.

Is there any way that you can make some of the toolbars more context sensitive? It seems rather unlikely that all 1000+ of your toolbar items would actually be relevant to any particular state of the application. Instead of displaying every possible action, just display those for which the prerequisites are met: if you have an option to make a line through two points, don't display it until 2 points are actually selected.

The key thing to remember is that user interfaces should be driven by what the user needs to do and see at any given point in time.

4
ответ дан 3 November 2019 в 14:19
поделиться

Adobe Photoshop approaches (I can't say "solves") this issue through pallets of controls. The individual pallets can float on the screen, be docked to the window, and can have tabs inside them with additional pallets. Also, most pallets can have a context menu with access to meta-settings for the pallet itself.

It also has a number of key items in a traditional toolbar, some of which change dynamically as the context changes. For instance, when you begin to stretch a layer, a box appears where you can type an exact dimension. When you change tools, the toolbar changes to include controls that relate only to that tool. And so forth.

One good thing about this approach is that many heavy users have multiple monitors and it is often practical and useful to float many pallets onto a second monitor.

I think it works partly because the controls are sensibly collected into the pallets so that related controls are together.

I'm certain it has an upper bound for number of total controls, however.

3
ответ дан 3 November 2019 в 14:19
поделиться

Can you describe what you're doing a bit more? From the sounds of things it's a CAD tool.

In this case, I may do something a bit different but also common.

I would firstly suggest make everything as context-sensitive as possible, and then, do this:

  1. Place very very common and general functions at the top
  2. Create a entirely new window for managing the rest of the buttons

The new window will sit off on the second monitor of the user. It can be large and extravagent, and contain searching and large icons for getting around inside it. Specifically, however, I may also add an ability for it to be navigated very fast, using the numpad.

You may detect, in the main window, when the numpad has focus and is being used, and take that as input to searching for specific commands in the offset window. Perhaps you can group them all so 100 functions exist per group, and for functions of type X, you start with a "9". I don't know your user base, and this would be only appropriate if people start to become experts in the software, but I think it's not a bad model in-general (a window off to the side to manage all these actions).

2
ответ дан 3 November 2019 в 14:19
поделиться

У пользователя две руки. Один обычно на клавиатуре для клавиш-модификаторов и тому подобное, а другой - на мыши. У пользователя САПР, вероятно, есть очень хорошая мышь с 5 или 6.

Я считаю, что мне может понравиться интерфейс, который всплывает вокруг текущего положения мыши. Не только контекстное меню, вызываемое щелчком правой кнопкой мыши, но и окружающее мышь текстовым меню, панелью инструментов со значками или тремя. Может быть, два контекстных меню. Это не обязательно должно быть радиальным, хотя радиальное выглядит красиво. Мне нравится радиальное разнесение с большим отверстием в центре, чтобы область вокруг мыши оставалась видимой. Но интерфейс мог быть прямоугольным и работать нормально.

Тогда я бы использовал пальцы левой руки на клавиатуре. Назначьте 12345 функциям в одном наборе инструментов / меню. Назначьте qwert для другого набора инструментов / меню и asdfg и zxcvb . Дайте пробелу большую важную функцию и, конечно же, Ctrl, Alt, Shift, даже Caps Lock.

Затем используйте последовательности этих простых нажатий левой клавиши для выбора функций. asdf и qwer должны получить самое важное. Для нового пользователя каждое нажатие клавиши должно обновлять отображение меню, чтобы они могли видеть, что происходит. Для опытного пользователя дисплей никогда не должен замедлять ввод команды.

О, и иметь быстрый способ повторить последнюю команду и, возможно, 2-5-ю последнюю команду. Может быть, иметь видимый последний стек команд и использовать числа от 1 до 5, чтобы переместить другую команду в верхнюю часть стека, и другую легко нажимаемую клавишу, такую ​​как обратный тик, для запуска верхней команды в стеке.

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

Конечно, мышь все еще можно использовать для навигации и выбора команд. Но я думаю, что метод клавиатуры даст лучшую скорость, как и vi , как это делает текстовый редактор. Я думаю, что необходимость удерживать Ctrl Alt и Shift и нажимать клавиши левой рукой приводит к судорогам пальцев.

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

Конечно, мышь все еще можно использовать для навигации и выбора команд. Но я думаю, что метод клавиатуры даст лучшую скорость, как и vi , как это делает текстовый редактор. Я думаю, что необходимость удерживать Ctrl Alt и Shift и нажимать клавиши левой рукой приводит к судорогам пальцев.

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

Конечно, мышь все еще можно использовать для навигации и выбора команд. Но я думаю, что клавиатурный метод даст лучшую скорость, как и vi , как это делает текстовый редактор. Я думаю, что необходимость удерживать Ctrl Alt и Shift и нажимать клавиши левой рукой приводит к судорогам пальцев.

2
ответ дан 3 November 2019 в 14:19
поделиться

Одна альтернатива, которую я видел в программах ГИС, - отказаться от размещения этого элемента в верхней части окно вообще. Например, ArcGIS помещает (очень мало) довольно распространенных «команд» в меню / панели инструментов, но затем имеет целое закрепленное окно в их пользовательском интерфейсе (которое можно включать и выключать), которое обеспечивает древовидное представление всех доступных (они называют это ArcToolbox - не слишком изобретательное название с их стороны, но оно имеет смысл для их пользователей).

У этого есть немало преимуществ - Основное из них состоит в том, что вы можете иметь иерархическую, категоризированную структура команд, довольно быстрая для навигации. Кроме того, подключаемость становится довольно простой, поскольку подключаемые модули могут просто добавлять команды в дерево или создавать новые узлы дерева.

Это '

1
ответ дан 3 November 2019 в 14:19
поделиться

Вы можете рассмотреть возможность изучения методов с веб-сайтов, поскольку веб-сайты с сотнями страниц встречаются чаще, чем приложения с сотнями кнопок.

Решение, очень похожее на веб-интерфейс, - это добавить поиск команда "поле". Это действительно требует, чтобы пользователь использовал клавиатуру, но если вы хорошо проиндексируете команды, им не придется запоминать имена всех команд, а только то, что они делают.

Одна из возможностей - сделать вашу панель вкладок и инструментов иерархической. например, на скриншоте, который вы показали, «Анализ», «Произвольная форма», «Примитив» и «Утилита» будут вкладками под поверхностью.

Чтобы выяснить, как классифицировать вещи, вы можете попробовать захватить некоторых типичных пользователей и выполнить тесты сортировки карточек . С 1000 карточек может быть немного сложно, но вы узнаете, как ваши пользователи хотят сгруппировать кнопки.

Dav '

1
ответ дан 3 November 2019 в 14:19
поделиться

эти кнопки предназначены для таких команд, как «Линия между 2 точками», «Обвод через 3 точки» и т. Д. И т. Д. Многие современные приложения САПР имеют сотни, если не тысячи инструментов для управления геометрией.

Мне это бросается в глаза , как большой провал. Может быть, поэтому я всегда считал программы САПР такими невероятно сложными и разочаровывающими в использовании.

Вот как я на это смотрю. Что мы делали до появления CAD? Карандаш и бумага с линейкой, циркулем, треугольниками, таврами, французскими кривыми и т. Д. Таким образом, переход к компьютеру был осуществлен путем превращения каждого инструмента в «инструмент». Затем, чтобы добавить больше функций, вы добавляете больше «инструментов».

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

Ну, мой компьютер может нарисовать идеальный круг, и само понятие «инструменты» к нему не имеет отношения. Посмотрите несколько старых видеороликов о взаимодействии человека с компьютером, еще до того, как мы узнали, что такое «панели инструментов». На RAND's GRAIL, если вы хотели что-то удалить, вы бы это нацарапали. Если вы хотите нарисовать коробку с отрубленным углом, вы рисуете коробку, а затем отрезаете угол. В блокноте Ивана Сазерленда, если я хочу провести линию между двумя точками, я рисую линию между двумя точками, и компьютер понимает ограничение, согласно которому линия должна быть между этими двумя точками. Это не то, что сложно вычислить компьютеру.

Я не знаю, какие 1000 вещей делает ваша программа CAD, но я думаю, что они, вероятно, попадают в относительно небольшое количество категорий:

  • рисовать новые вещи
  • растягивать / деформировать предметы
  • перемещать предметы (часто с одной фиксированной точкой / осью / стороной / и т. д.)
  • удалить вещи
  • ...

Так зачем мне больше, чем несколько инструментов? Если я нарисую волнистый круг, скорее всего, мне понадобится настоящий круг. Позвольте мне нарисовать и понять, чего я хочу. Не заставляйте меня использовать какие-либо панели инструментов.

5
ответ дан 3 November 2019 в 14:19
поделиться

Дэвид,

Это сообщение довольно старое, но я решил ответить, так как я заядлый пользователь вашего программного обеспечения, Grasshopper, а также Stack Overflow. При использовании компонентов в вашем ПО я обычно нахожусь в двух разных режимах: ищу компоненты, о которых я уже знаю, или выясняю, какие другие компоненты доступны, которые могли бы выполнить то, чего я пытаюсь достичь.

При использовании компонентов, о которых я уже знаю, в 99% случаев я использую функцию двойного щелчка на холсте и ввода всего или части названия компонента. Даже когда я ищу новые компоненты, я чаще использую эту функцию, чем панель инструментов. Скажем, я знаю, что хочу разделить линию, но не знаю, где находится значок. Я просто введу имя "Разделить", чтобы найти все команды с "Разделить" в названии.

Хотя панель инструментов полезна для просмотра общего представления о том, что доступно. В итоге я трачу много времени на перетаскивание компонентов только для того, чтобы посмотреть, какие входы они принимают. Поэтому я думаю, что было бы полезно сделать панель инструментов более динамичной и чувствительной к контексту. Например, если пользователь выбирает компонент, который может выводить точки, то я хотел бы видеть отдельную панель инструментов, которая показывает только те компоненты, которые могут принимать точки в качестве входа. Autodesk Revit имеет подобную функциональность, где, например, если пользователь выберет стену, ему будут представлены все инструменты, связанные с изменением стен.

С вашим программным обеспечением это было бы легко, так как вы могли бы просто сопоставить выходные данные выбранного в данный момент компонента с входными данными всех доступных компонентов для создания динамической вкладки. В конечном итоге это позволило бы пользователям быстро ответить на вопрос "куда мне двигаться дальше", выбирая отдельные компоненты в их текущем определении.

1
ответ дан 3 November 2019 в 14:19
поделиться

Несколько меток и всплывающих подсказок (и логическая группировка!) могут помочь долгий путь: взгляните на пользовательский интерфейс в Office 2007/2010; Это действительно хорошо (люди жалуются, потому что это не так, как было раньше).

А теперь представьте тот же пользовательский интерфейс без меток на кнопках ...

Просто добавьте метки к своим кнопкам и сгруппируйте их в раскрывающиеся списки , и ваш пользовательский интерфейс будет великолепным!

0
ответ дан 3 November 2019 в 14:19
поделиться
Другие вопросы по тегам:

Похожие вопросы: