Here's a screenshot of the duty calendar in the system I'm working on (I've deleted all names here for privacy reasons).
Each person can have a day of particular type (listed in the legend above: working day, friday (i.e. shortened) etc.).
Those types are changing in a way shown in the picture: first you click in the type inside the legend (legend changes it's background) and then put it in the calendar - just like color picker in photoshop.
So: is this method good or do I have to think of something else?
Answer
The Right Information
Firstly, make sure your displays show the information the user needs to make good decisions and input. The use of a color-coded matrix assumes that your user is trying to achieve a certain pattern of assignments, such as a certain number of people in each duty type per day (e.g., have adequate coverage when some are on vacation), or systematic rotation of duties among the workers, or cyclic frequencies of duties per month. It implies that the user sits down each month and plans the roster. If that’s the way users do things, then it’s fine. Your user research will tell you if that’s the case.
Consider an alternative where the pattern of duties over workers and time doesn’t matter. What if, instead, assigning a person to a duty depended on their rank, training, level of experience, and sock color? That would imply a very different interface that focuses on the characteristics of the individual rather than the pattern of duties over a month, perhaps a UI showing one worker per page. Possibly, duty assignment involves relative individual characteristics, so you want a table to see who has higher values of relevant characteristics for duty assignment. Possibly both the monthly pattern and individual characteristics are important, so you need to show both.
The Right Input
Assuming the matrix is the way to go, your suggested method of input is a good way to do it. I call it a pointer-tool input, which, as you note, is similar to the “palettes” of “tools” (there’s a mixed metaphor) used in drawing and image manipulation programs (e.g., to fill a space with a certain color). IMO, pointer-tool is underutilized.
The main alternative is basic selection-action input. Here, the user selects the days for each worker first then selects a command button to set the duty for the selected worker-days.
Assuming you’re supporting multi-selection in either case (with dragging, control-clicking, and shift-clicking), both methods are about equally efficient. The main difference is that pointer-tool puts the user in a mode. That’s good if the user tends to stay with assigning one kind of duty for a long time, gradually filling the matrix with that duty. In contrast, selection-action in such a case means lots of single-selection of a worker-day followed by a command button, a two-step process that gets old fast (although putting the Duty commands on a context menu would make it a lot easier). Or the user of selection-action uses Ctrl-click to select a complicated pattern of worker-days to set them all to a single duty, but then accidentally clicks somewhere else blowing away the multi-selection. That error can’t happen with pointer-tool.
The main problem with pointer-tool is that users may forget what mode they’re in and accidentally set a bunch of worker-days to the wrong duty with a single swipe of the hand. Obviously you should have Undo whether you use pointer-tool or selection-action, so that should only be a mild annoyance, but it is something to consider. The main way to combat mode-forgetting is with strong feedback on the current mode. The currently selected duty should be obvious (I don’t see that in the wireframe), and the sprite (pointer symbol) should change to represent the current duty (both with color and shape, in your case).
Another potential issue is that many users are less familiar with pointer-tool than selection-action, but that has to be weighed against similar unfamiliarity with multi-selection, which may be a critical skill for efficiently using selection-action. Check with your users. If they are familiar with Photoshop, then pointer-tool will probably work okay, especially if you make your duty menu look more like a tool palette and less like a bar of buttons.
The bottom line is selection-action is probably better when there is a lot of switching between duty types, while pointer-tool is better when users stick with one duty type for many interactions. Your user research will tell you which is compatible with your users.
Details make the Difference
Beyond the form of input, consider what you can do to attend to the details of the users’ specific task. That will make the bigger difference in the UX than pointer-tool versus selection-action. This may include:
Multi-selection, which I already mentioned, so that users can set a whole block of worker-days to the same duty (probably especially handy for assigning vacation times).
Good defaults minimizing the amount of work in the first place. Perhaps each new month can by default be the same as the previous month. Or perhaps Fridays should by default all be the Friday Duty. Whatever saves your users work.
Automation tools that allow the user to set a common pattern for a given worker(s) or day(s) ( e.g., standard rotation of duties).
Aggregates showing counts or other statistics of each duty type in the margins, which may be important for achieving target numbers of duties per day or per worker.
Copying and moving allowing users to duplicate or shift a block of duties to a different set of days and/or workers. This may be through Cut/Copy and Paste, supplemented with drag-and-drop. Note that for pointer-tool, this implies you need a generic Selection tool in addition to your duty tools.
Redundant codes where shade or distinct symbols also indicate the duty of the worker-day. This is primarily for accessibility reasons, but a symbol may also be easier to learn and remember than a color code, reducing the need for the user to refer to the legend/palette/toolbar. With some work on the graphic design so it’s easier to use the column header, you can show the symbol instead of the date in the worker-day.
As always, the needs for such things are determined from user research.
No comments:
Post a Comment