2

I just had a catch-22 from production that I have no good answer for:

The user has a partial calendar (there are no month or year breaks, it's just an eternal scroll of weeks) displayed, each day of the calendar has a list of jobs that are scheduled for that day. Jobs may be dragged around subject to production and scheduling rules. Things are busy, most days are full.

A job had to be pushed back--and every date on the screen rejected it. The only place to find a valid drop target was farther down the list than the time it was showing. Reportedly (reproducing this on my system would be difficult but the reporter is competent) the scroll wheel would not work while they were in the middle of a drag.

Allowing them to alter the number of weeks being displayed runs a considerable risk of overflowing a cell and hiding the job they are trying to move. I could make each cell scrollable if need be but scrollable windows within a scrollable window does not strike me as user friendly and just screams focus issues.

The other answer that comes to mind is an option with a date prompt--which lacks the context of what's around the target and thus invites user errors.

How ugly a solution am I going to have to provide here?

(Admittedly, it would be hard to be as ugly as the quick fix of moving the offending job with SQL was!)

  • if i understand you correctly , you need to highlight the target with different color when you start dragging , that is it. – mussdroid Jan 12 '16 at 5:42
  • @mussdroid The problem was there was no way to get a valid drop target on screen. – Loren Pechtel Jan 12 '16 at 20:16
0

As well as handling scrolling the screen, what about handling the failed drop as well?

So if a user tries to drop a job where there is no space, handle it by displaying a message like:


No available spot could be found for the selected job.

[Find the first available spot] [Cancel action]

If the first button is chosen, the system then looks for the first upcoming space that is available, drops the job in and shows the user where that is (i.e. scrolls the screen to the date where it was added).

  • Most of the time a failed drop doesn't mean there's no option. They have been dragging things around for several weeks now before they got stuck. You have given me an idea, though--there's already a pop-up menu, I think I'll add "Move to <date>" where <date> is the first available. – Loren Pechtel Jan 12 '16 at 21:56
  • While this answer isn't anything like perfect the "Move to <first available date>" option worked well and your message gave me the idea so I'm accepting it. – Loren Pechtel May 1 '16 at 4:17
2

Would something like permanent drag targets of "Next week" or "Previous week" in the footer (or header) of your scrolling calendar area work?

I'm imagining a user starts dragging, doesn't see their date, so hovers over "Next Weeks", which scrolls the calendar week one at a time at a slow pace as long as they hover over it.

---------------------------------------
Day 1 | Day 2 | ...
Day 8 | Day 9 | ...
[ Next week V ]    [ ^ Previous week]
---------------------------------------
1

How about smart auto-zoom interaction?

Let's say, initially they see limited number of the large-sized cells, see the image:
enter image description here

When they drag close to the edge, the cells are zoomed out, so they see minified calendar view, which contains all the cells, see the image:
enter image description here Note: all the 365 days are visible even on quite small notebook screen.

The white cells are available for job placing, while gray ones are the buzy.

This interaction provides great observability of the days. Still, there are some constraints: cells size should be large enough to provide efficient targeting (considering the Fitts's law).

After placing the cell the view is returned to previous zoom level.

  • Interesting idea, I'll have to run it by the guys using it. It would only expand in the vertical direction, it should remain one week wide no matter what. – Loren Pechtel Jan 13 '16 at 0:24
0

A simpler solution without changing much for now could be - As soon as user with a dragged item comes near the vicinity of the last row in the viewport, the view automatically updates and shows the next set - with the last row in the previous view as the first one in the new view. Alternatively, there could be a drop target ( like a mini row) at the viewport end - which when employed shifts view.

You could use intelligent affordances to help the user understand this. As soon as one comes near the last row with a dragged item - a text/UI hint could indicate the same.

0

With the way, you are currently set up, you have to realize you have limitations on the length of screen you can scroll - to drop a job into another date. If both source and target dates are in the visible zone, you do not have issues. You need to have another zone to drag the date to (like an over flow zone shown to the right in grey in the below picture) that triggers either a prompt asking the user for target date (that could be entered) or scrolls the display to the target date entered. Something like this will work?

enter image description here

  • You still need a target date. (And there's no time involved--jobs are scheduled for a day, not for a time during the day. This is to ensure there isn't more work on a day than labor to do that work.) – Loren Pechtel Jan 12 '16 at 22:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.