Simplify an interface for flexibly applying rules to periods of timeBest practices for selecting timeUser Interface for assigning times throughout the dayGood metaphor for time estimation vs. spent timeBuilding logical criteria (with AND , OR, etc)Is there a pattern for cycling or toggling through time periods?Approaches for setting a time periodDisplaying time spans - do you show both periods? What about past 12:00?Clock face interface for time selectionGraphical alternatives to mini-language to operate on large setsHow to handle time input for different time zones?
Are all passive ability checks floors for active ability checks?
What does 高層ビルに何車線もの道路。mean?
Why do newer 737s use two different styles of split winglets?
If I can solve Sudoku, can I solve the Travelling Salesman Problem (TSP)? If so, how?
When to use a slotted vs. solid turner?
Python if-else code style for reduced code for rounding floats
What is "focus distance lower/upper" and how is it different from depth of field?
Happy pi day, everyone!
PTIJ: Who should I vote for? (21st Knesset Edition)
World War I as a war of liberals against authoritarians?
Why did it take so long to abandon sail after steamships were demonstrated?
Why Choose Less Effective Armour Types?
Professor being mistaken for a grad student
ERC721: How to get the owned tokens of an address
Is it true that good novels will automatically sell themselves on Amazon (and so on) and there is no need for one to waste time promoting?
How could an airship be repaired midflight?
How to pronounce "I ♥ Huckabees"?
What is the adequate fee for a reveal operation?
As a new Ubuntu desktop 18.04 LTS user, do I need to use ufw for a firewall or is iptables sufficient?
Why is the President allowed to veto a cancellation of emergency powers?
Fastest way to pop N items from a large dict
What did “the good wine” (τὸν καλὸν οἶνον) mean in John 2:10?
Book about superhumans hiding among normal humans
Is honey really a supersaturated solution? Does heating to un-crystalize redissolve it or melt it?
Simplify an interface for flexibly applying rules to periods of time
Best practices for selecting timeUser Interface for assigning times throughout the dayGood metaphor for time estimation vs. spent timeBuilding logical criteria (with AND , OR, etc)Is there a pattern for cycling or toggling through time periods?Approaches for setting a time periodDisplaying time spans - do you show both periods? What about past 12:00?Clock face interface for time selectionGraphical alternatives to mini-language to operate on large setsHow to handle time input for different time zones?
We have a module in an application where users define time periods for different criteria that will be used later to filter some lists.
By default each criterion applies any time. Its validity can be limited by both restricting the time periods where it applies, and adding exclusion time periods. Already-defined periods of applying and excluding can be edited or deleted.
The current interface is as follow:
download bmml source – Wireframes created with Balsamiq Mockups
Users find it difficult to understand the logic of "application" vs "exclusion" time periods, which I totally understand.
I can't find a solution to simplify the interface while keeping all the existing possibilities.
What can be done to improve the user's experience here?
usability gui-design time simplicity
|
show 5 more comments
We have a module in an application where users define time periods for different criteria that will be used later to filter some lists.
By default each criterion applies any time. Its validity can be limited by both restricting the time periods where it applies, and adding exclusion time periods. Already-defined periods of applying and excluding can be edited or deleted.
The current interface is as follow:
download bmml source – Wireframes created with Balsamiq Mockups
Users find it difficult to understand the logic of "application" vs "exclusion" time periods, which I totally understand.
I can't find a solution to simplify the interface while keeping all the existing possibilities.
What can be done to improve the user's experience here?
usability gui-design time simplicity
2
what is the smallest and largest units of time here? How small can an exception be to a restriction?
– Mike M
2 days ago
1
ah okay, see my answer, i would say then you wouldn't have the 'gray' area in between it sounds like.
– Mike M
2 days ago
1
I can't edited only two characters due to low rep, but the singular of criteria is criterion.
– henning
2 days ago
1
Submitting a comment since you mentioned keeping functionality. Having "application" vs. "exclusion" doesn't seem helpful conceptually or for data entry. For example, in your criteria 3, the user must enter two date ranges (4 dates). So why not just enter the two date ranges for application: 2019/1/1 through 2019-7-14, and 2019-8-15 through 2019-12-31? If you have one range of "application" with 2 periods of "exception", this is the same thing as 3 ranges of "application." Either way, the user still has to enter 6 dates. What does the application vs. exception distinction buy you?
– Randall Stewart
2 days ago
2
What purpose do these exceptions serve? Why is it preferred to input "Applies from 2019-01-01 to 2019-12-31, except from 2019-07-14 to 2019-08-15" and not simply "Applies from 2019-01-01 to 2019-07-14 and 2019-08-15 to 2019-12-31". Same functionality, but you reduce the available inputs a lot.
– Polygnome
2 days ago
|
show 5 more comments
We have a module in an application where users define time periods for different criteria that will be used later to filter some lists.
By default each criterion applies any time. Its validity can be limited by both restricting the time periods where it applies, and adding exclusion time periods. Already-defined periods of applying and excluding can be edited or deleted.
The current interface is as follow:
download bmml source – Wireframes created with Balsamiq Mockups
Users find it difficult to understand the logic of "application" vs "exclusion" time periods, which I totally understand.
I can't find a solution to simplify the interface while keeping all the existing possibilities.
What can be done to improve the user's experience here?
usability gui-design time simplicity
We have a module in an application where users define time periods for different criteria that will be used later to filter some lists.
By default each criterion applies any time. Its validity can be limited by both restricting the time periods where it applies, and adding exclusion time periods. Already-defined periods of applying and excluding can be edited or deleted.
The current interface is as follow:
download bmml source – Wireframes created with Balsamiq Mockups
Users find it difficult to understand the logic of "application" vs "exclusion" time periods, which I totally understand.
I can't find a solution to simplify the interface while keeping all the existing possibilities.
What can be done to improve the user's experience here?
usability gui-design time simplicity
usability gui-design time simplicity
edited 6 hours ago
Community♦
1
1
asked 2 days ago
Yannick BlondeauYannick Blondeau
1,25021322
1,25021322
2
what is the smallest and largest units of time here? How small can an exception be to a restriction?
– Mike M
2 days ago
1
ah okay, see my answer, i would say then you wouldn't have the 'gray' area in between it sounds like.
– Mike M
2 days ago
1
I can't edited only two characters due to low rep, but the singular of criteria is criterion.
– henning
2 days ago
1
Submitting a comment since you mentioned keeping functionality. Having "application" vs. "exclusion" doesn't seem helpful conceptually or for data entry. For example, in your criteria 3, the user must enter two date ranges (4 dates). So why not just enter the two date ranges for application: 2019/1/1 through 2019-7-14, and 2019-8-15 through 2019-12-31? If you have one range of "application" with 2 periods of "exception", this is the same thing as 3 ranges of "application." Either way, the user still has to enter 6 dates. What does the application vs. exception distinction buy you?
– Randall Stewart
2 days ago
2
What purpose do these exceptions serve? Why is it preferred to input "Applies from 2019-01-01 to 2019-12-31, except from 2019-07-14 to 2019-08-15" and not simply "Applies from 2019-01-01 to 2019-07-14 and 2019-08-15 to 2019-12-31". Same functionality, but you reduce the available inputs a lot.
– Polygnome
2 days ago
|
show 5 more comments
2
what is the smallest and largest units of time here? How small can an exception be to a restriction?
– Mike M
2 days ago
1
ah okay, see my answer, i would say then you wouldn't have the 'gray' area in between it sounds like.
– Mike M
2 days ago
1
I can't edited only two characters due to low rep, but the singular of criteria is criterion.
– henning
2 days ago
1
Submitting a comment since you mentioned keeping functionality. Having "application" vs. "exclusion" doesn't seem helpful conceptually or for data entry. For example, in your criteria 3, the user must enter two date ranges (4 dates). So why not just enter the two date ranges for application: 2019/1/1 through 2019-7-14, and 2019-8-15 through 2019-12-31? If you have one range of "application" with 2 periods of "exception", this is the same thing as 3 ranges of "application." Either way, the user still has to enter 6 dates. What does the application vs. exception distinction buy you?
– Randall Stewart
2 days ago
2
What purpose do these exceptions serve? Why is it preferred to input "Applies from 2019-01-01 to 2019-12-31, except from 2019-07-14 to 2019-08-15" and not simply "Applies from 2019-01-01 to 2019-07-14 and 2019-08-15 to 2019-12-31". Same functionality, but you reduce the available inputs a lot.
– Polygnome
2 days ago
2
2
what is the smallest and largest units of time here? How small can an exception be to a restriction?
– Mike M
2 days ago
what is the smallest and largest units of time here? How small can an exception be to a restriction?
– Mike M
2 days ago
1
1
ah okay, see my answer, i would say then you wouldn't have the 'gray' area in between it sounds like.
– Mike M
2 days ago
ah okay, see my answer, i would say then you wouldn't have the 'gray' area in between it sounds like.
– Mike M
2 days ago
1
1
I can't edited only two characters due to low rep, but the singular of criteria is criterion.
– henning
2 days ago
I can't edited only two characters due to low rep, but the singular of criteria is criterion.
– henning
2 days ago
1
1
Submitting a comment since you mentioned keeping functionality. Having "application" vs. "exclusion" doesn't seem helpful conceptually or for data entry. For example, in your criteria 3, the user must enter two date ranges (4 dates). So why not just enter the two date ranges for application: 2019/1/1 through 2019-7-14, and 2019-8-15 through 2019-12-31? If you have one range of "application" with 2 periods of "exception", this is the same thing as 3 ranges of "application." Either way, the user still has to enter 6 dates. What does the application vs. exception distinction buy you?
– Randall Stewart
2 days ago
Submitting a comment since you mentioned keeping functionality. Having "application" vs. "exclusion" doesn't seem helpful conceptually or for data entry. For example, in your criteria 3, the user must enter two date ranges (4 dates). So why not just enter the two date ranges for application: 2019/1/1 through 2019-7-14, and 2019-8-15 through 2019-12-31? If you have one range of "application" with 2 periods of "exception", this is the same thing as 3 ranges of "application." Either way, the user still has to enter 6 dates. What does the application vs. exception distinction buy you?
– Randall Stewart
2 days ago
2
2
What purpose do these exceptions serve? Why is it preferred to input "Applies from 2019-01-01 to 2019-12-31, except from 2019-07-14 to 2019-08-15" and not simply "Applies from 2019-01-01 to 2019-07-14 and 2019-08-15 to 2019-12-31". Same functionality, but you reduce the available inputs a lot.
– Polygnome
2 days ago
What purpose do these exceptions serve? Why is it preferred to input "Applies from 2019-01-01 to 2019-12-31, except from 2019-07-14 to 2019-08-15" and not simply "Applies from 2019-01-01 to 2019-07-14 and 2019-08-15 to 2019-12-31". Same functionality, but you reduce the available inputs a lot.
– Polygnome
2 days ago
|
show 5 more comments
6 Answers
6
active
oldest
votes
Try showing them visually, as they build the restriction and exemption times. With each criterion added, the timeline updates.
I'm not sure I fully understand your use case, but it sounds like users need to clearly see the results of their restrictions and exceptions. I'm focusing a little bit on how to see the outcome as feedback.
Forcing them to read and calculate dates (and proportional allocations) seems to add to their workload. They also might have to look at periods across each criterion as well.
Could you have a visualization that aids in showing them as they add criteria?
A heatmap example:
Github is an example of showing a years worth of data. At a glance, you can see periods of activity.
Don't make them read; provide visuals in tandem.
If there's another state (i'm not too clear on this): that of unrestricted and undeclared time, the heatmap can show these gaps as well.
Thanks Mike, that's a great idea indeed. Regarding the possible status of each day, a criteria is either "applied" or not: by default it's applied anytime. If you restrict the application to only one week for example, then all the other dates become "exceptions"...
– Yannick Blondeau
2 days ago
Also, it's probably better to display weekdays horizontally, since that's the most common calendar layout and what users would expect. That GitHub graph always makes me stare at it for a while before I can figure it out.
– typo
11 hours ago
add a comment |
I hope I am not misunderstanding your needs, but my recommendation is to do away with the exception/exclusion periods, as they are merely reinstating the default (criterion* applies) in a period of "restriction" (criterion does not apply). Intuitively it might appear simpler to say (as in your 3rd example) "The criterion should apply all year, except for a summer break", but you need two lines to say it, and you might as well say (in the same space, without the mental calisthenics):
Applies from 2019-01-01 to 2019-07-13
Applies from 2019-08-16 to 2019-12-31
To allow insertion of an exception more easily, I would recommend a split
(or similarly named) button (in addition to edit
and delete
), which would double the current line and prefill the start of the first and the end of the second line with the start and end of the original line. A color-coded calendar to help visualize this (as suggested in other answers) would certainly be helpful but is not strictly required.
By the way, your example criterion 1 is simply the equivalent of Applies from -infinity to infinity
.
*) "Criteria" is the plural of "criterion" (a standard or a trait) or of "criterium" (a bike race).
New contributor
1
Instead of a "split" button, if the exceptions are a common use case why not just keep the "add exception" button and calculate the resulting timeframes where the criterion applies? So the user would punch in "applies from 01/01 to 31/12" and "doesn't apply from 13/07 to 16/08" and the application would display the dates as above.
– Maciej Stachowski
yesterday
add a comment |
Overlap of rules
I apologize if I misunderstood the ASK, but I feel this is a classic case of AND & OR operations (kind of :P).
- Users add a rule (set up time period) i.e Application
- Users can add another rule on top of the above rule i.e Exception, which may or may not overlap with the set time period.
Since the application and exception are closely tied to the mental map when creating, instead of giving them separate hierarchies I feel they should have parent/child relationship.
My proposal
I love how Zapier visualizes the AND/OR operations.
In close to the above design, your interface can look like
New contributor
Could you clarify what ASK stands for?
– Lightness Races in Orbit
yesterday
Sorry for the confusion, by ASK I mean the problem statement in the question. @LightnessRacesinOrbit
– tridip1931
19 hours ago
So you mean the "question"? Not sure why this normal word was capitalised and bolded; that made it look like an acronym. Thanks for your answer!
– Lightness Races in Orbit
13 hours ago
add a comment |
Instead of placing action buttons at the bottom, place "Add" buttons in each section.
Applies:
From 2019-01-01 to 2019-12-31 edit delete
+ Add
Except:
From 2019-07-14 to 2019-08-15 edit delete
+ Add
3
That would simplify things for sure, thanks. Unfortunately that wouldn't help with users being lost with the different periods definition...
– Yannick Blondeau
2 days ago
add a comment |
Usually simplifying the copy language helps (something like "add valid time range" & "block specific dates".
A second option would be adding colors such as green (for restricted times) and red (for exception times), following the logic:
Green => go, Red =>stop
A third option is to add an icon (+ for add, - for restricting).
Best if you do all three together, this makes sure you cover more users' logics (i.e. graphic-oriented vs readers) Try to think of the user as if you were talking to a kid ;) this always helps me!
1
This is not accessible. Red-green colour blindness is prevalent (and the meaning of red/green can also differ across cultures)
– Lightness Races in Orbit
yesterday
add a comment |
The problem is that you are presenting the rules, but not the result.
As a litmus test, try to answer the question: is the criterion applied on Mar 23rd?
Instead of:
Applies from 2019-01-01 to 2019-12-31
Except from 2019-07-14 to 2019-08-15
The following display is easier to reason about... especially as exceptions pile up:
Applies from 2019-01-01 to 2019-07-13
Applies from 2019-08-16 to 2019-12-31
It could also be helpful to make this more visual. Calendars would be greatly helpful; especially with clicking to toggle on/off and SHIFT+click or CTRL+click to mass select/unselect.
If space is limited, even with text you could add extra information to help the user:
Applies from 2019-01-01 to 2019-07-13 (x days)
-- y days later --
Applies from 2019-08-16 to 2019-12-31 (z days)
This order of magnitude check can help the user identifying typos.
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "102"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fux.stackexchange.com%2fquestions%2f124401%2fsimplify-an-interface-for-flexibly-applying-rules-to-periods-of-time%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
6 Answers
6
active
oldest
votes
6 Answers
6
active
oldest
votes
active
oldest
votes
active
oldest
votes
Try showing them visually, as they build the restriction and exemption times. With each criterion added, the timeline updates.
I'm not sure I fully understand your use case, but it sounds like users need to clearly see the results of their restrictions and exceptions. I'm focusing a little bit on how to see the outcome as feedback.
Forcing them to read and calculate dates (and proportional allocations) seems to add to their workload. They also might have to look at periods across each criterion as well.
Could you have a visualization that aids in showing them as they add criteria?
A heatmap example:
Github is an example of showing a years worth of data. At a glance, you can see periods of activity.
Don't make them read; provide visuals in tandem.
If there's another state (i'm not too clear on this): that of unrestricted and undeclared time, the heatmap can show these gaps as well.
Thanks Mike, that's a great idea indeed. Regarding the possible status of each day, a criteria is either "applied" or not: by default it's applied anytime. If you restrict the application to only one week for example, then all the other dates become "exceptions"...
– Yannick Blondeau
2 days ago
Also, it's probably better to display weekdays horizontally, since that's the most common calendar layout and what users would expect. That GitHub graph always makes me stare at it for a while before I can figure it out.
– typo
11 hours ago
add a comment |
Try showing them visually, as they build the restriction and exemption times. With each criterion added, the timeline updates.
I'm not sure I fully understand your use case, but it sounds like users need to clearly see the results of their restrictions and exceptions. I'm focusing a little bit on how to see the outcome as feedback.
Forcing them to read and calculate dates (and proportional allocations) seems to add to their workload. They also might have to look at periods across each criterion as well.
Could you have a visualization that aids in showing them as they add criteria?
A heatmap example:
Github is an example of showing a years worth of data. At a glance, you can see periods of activity.
Don't make them read; provide visuals in tandem.
If there's another state (i'm not too clear on this): that of unrestricted and undeclared time, the heatmap can show these gaps as well.
Thanks Mike, that's a great idea indeed. Regarding the possible status of each day, a criteria is either "applied" or not: by default it's applied anytime. If you restrict the application to only one week for example, then all the other dates become "exceptions"...
– Yannick Blondeau
2 days ago
Also, it's probably better to display weekdays horizontally, since that's the most common calendar layout and what users would expect. That GitHub graph always makes me stare at it for a while before I can figure it out.
– typo
11 hours ago
add a comment |
Try showing them visually, as they build the restriction and exemption times. With each criterion added, the timeline updates.
I'm not sure I fully understand your use case, but it sounds like users need to clearly see the results of their restrictions and exceptions. I'm focusing a little bit on how to see the outcome as feedback.
Forcing them to read and calculate dates (and proportional allocations) seems to add to their workload. They also might have to look at periods across each criterion as well.
Could you have a visualization that aids in showing them as they add criteria?
A heatmap example:
Github is an example of showing a years worth of data. At a glance, you can see periods of activity.
Don't make them read; provide visuals in tandem.
If there's another state (i'm not too clear on this): that of unrestricted and undeclared time, the heatmap can show these gaps as well.
Try showing them visually, as they build the restriction and exemption times. With each criterion added, the timeline updates.
I'm not sure I fully understand your use case, but it sounds like users need to clearly see the results of their restrictions and exceptions. I'm focusing a little bit on how to see the outcome as feedback.
Forcing them to read and calculate dates (and proportional allocations) seems to add to their workload. They also might have to look at periods across each criterion as well.
Could you have a visualization that aids in showing them as they add criteria?
A heatmap example:
Github is an example of showing a years worth of data. At a glance, you can see periods of activity.
Don't make them read; provide visuals in tandem.
If there's another state (i'm not too clear on this): that of unrestricted and undeclared time, the heatmap can show these gaps as well.
edited yesterday
Solar Mike
1385
1385
answered 2 days ago
Mike MMike M
10.7k12331
10.7k12331
Thanks Mike, that's a great idea indeed. Regarding the possible status of each day, a criteria is either "applied" or not: by default it's applied anytime. If you restrict the application to only one week for example, then all the other dates become "exceptions"...
– Yannick Blondeau
2 days ago
Also, it's probably better to display weekdays horizontally, since that's the most common calendar layout and what users would expect. That GitHub graph always makes me stare at it for a while before I can figure it out.
– typo
11 hours ago
add a comment |
Thanks Mike, that's a great idea indeed. Regarding the possible status of each day, a criteria is either "applied" or not: by default it's applied anytime. If you restrict the application to only one week for example, then all the other dates become "exceptions"...
– Yannick Blondeau
2 days ago
Also, it's probably better to display weekdays horizontally, since that's the most common calendar layout and what users would expect. That GitHub graph always makes me stare at it for a while before I can figure it out.
– typo
11 hours ago
Thanks Mike, that's a great idea indeed. Regarding the possible status of each day, a criteria is either "applied" or not: by default it's applied anytime. If you restrict the application to only one week for example, then all the other dates become "exceptions"...
– Yannick Blondeau
2 days ago
Thanks Mike, that's a great idea indeed. Regarding the possible status of each day, a criteria is either "applied" or not: by default it's applied anytime. If you restrict the application to only one week for example, then all the other dates become "exceptions"...
– Yannick Blondeau
2 days ago
Also, it's probably better to display weekdays horizontally, since that's the most common calendar layout and what users would expect. That GitHub graph always makes me stare at it for a while before I can figure it out.
– typo
11 hours ago
Also, it's probably better to display weekdays horizontally, since that's the most common calendar layout and what users would expect. That GitHub graph always makes me stare at it for a while before I can figure it out.
– typo
11 hours ago
add a comment |
I hope I am not misunderstanding your needs, but my recommendation is to do away with the exception/exclusion periods, as they are merely reinstating the default (criterion* applies) in a period of "restriction" (criterion does not apply). Intuitively it might appear simpler to say (as in your 3rd example) "The criterion should apply all year, except for a summer break", but you need two lines to say it, and you might as well say (in the same space, without the mental calisthenics):
Applies from 2019-01-01 to 2019-07-13
Applies from 2019-08-16 to 2019-12-31
To allow insertion of an exception more easily, I would recommend a split
(or similarly named) button (in addition to edit
and delete
), which would double the current line and prefill the start of the first and the end of the second line with the start and end of the original line. A color-coded calendar to help visualize this (as suggested in other answers) would certainly be helpful but is not strictly required.
By the way, your example criterion 1 is simply the equivalent of Applies from -infinity to infinity
.
*) "Criteria" is the plural of "criterion" (a standard or a trait) or of "criterium" (a bike race).
New contributor
1
Instead of a "split" button, if the exceptions are a common use case why not just keep the "add exception" button and calculate the resulting timeframes where the criterion applies? So the user would punch in "applies from 01/01 to 31/12" and "doesn't apply from 13/07 to 16/08" and the application would display the dates as above.
– Maciej Stachowski
yesterday
add a comment |
I hope I am not misunderstanding your needs, but my recommendation is to do away with the exception/exclusion periods, as they are merely reinstating the default (criterion* applies) in a period of "restriction" (criterion does not apply). Intuitively it might appear simpler to say (as in your 3rd example) "The criterion should apply all year, except for a summer break", but you need two lines to say it, and you might as well say (in the same space, without the mental calisthenics):
Applies from 2019-01-01 to 2019-07-13
Applies from 2019-08-16 to 2019-12-31
To allow insertion of an exception more easily, I would recommend a split
(or similarly named) button (in addition to edit
and delete
), which would double the current line and prefill the start of the first and the end of the second line with the start and end of the original line. A color-coded calendar to help visualize this (as suggested in other answers) would certainly be helpful but is not strictly required.
By the way, your example criterion 1 is simply the equivalent of Applies from -infinity to infinity
.
*) "Criteria" is the plural of "criterion" (a standard or a trait) or of "criterium" (a bike race).
New contributor
1
Instead of a "split" button, if the exceptions are a common use case why not just keep the "add exception" button and calculate the resulting timeframes where the criterion applies? So the user would punch in "applies from 01/01 to 31/12" and "doesn't apply from 13/07 to 16/08" and the application would display the dates as above.
– Maciej Stachowski
yesterday
add a comment |
I hope I am not misunderstanding your needs, but my recommendation is to do away with the exception/exclusion periods, as they are merely reinstating the default (criterion* applies) in a period of "restriction" (criterion does not apply). Intuitively it might appear simpler to say (as in your 3rd example) "The criterion should apply all year, except for a summer break", but you need two lines to say it, and you might as well say (in the same space, without the mental calisthenics):
Applies from 2019-01-01 to 2019-07-13
Applies from 2019-08-16 to 2019-12-31
To allow insertion of an exception more easily, I would recommend a split
(or similarly named) button (in addition to edit
and delete
), which would double the current line and prefill the start of the first and the end of the second line with the start and end of the original line. A color-coded calendar to help visualize this (as suggested in other answers) would certainly be helpful but is not strictly required.
By the way, your example criterion 1 is simply the equivalent of Applies from -infinity to infinity
.
*) "Criteria" is the plural of "criterion" (a standard or a trait) or of "criterium" (a bike race).
New contributor
I hope I am not misunderstanding your needs, but my recommendation is to do away with the exception/exclusion periods, as they are merely reinstating the default (criterion* applies) in a period of "restriction" (criterion does not apply). Intuitively it might appear simpler to say (as in your 3rd example) "The criterion should apply all year, except for a summer break", but you need two lines to say it, and you might as well say (in the same space, without the mental calisthenics):
Applies from 2019-01-01 to 2019-07-13
Applies from 2019-08-16 to 2019-12-31
To allow insertion of an exception more easily, I would recommend a split
(or similarly named) button (in addition to edit
and delete
), which would double the current line and prefill the start of the first and the end of the second line with the start and end of the original line. A color-coded calendar to help visualize this (as suggested in other answers) would certainly be helpful but is not strictly required.
By the way, your example criterion 1 is simply the equivalent of Applies from -infinity to infinity
.
*) "Criteria" is the plural of "criterion" (a standard or a trait) or of "criterium" (a bike race).
New contributor
edited yesterday
Prajwal Dhatwalia
1826
1826
New contributor
answered 2 days ago
ThomasThomas
711
711
New contributor
New contributor
1
Instead of a "split" button, if the exceptions are a common use case why not just keep the "add exception" button and calculate the resulting timeframes where the criterion applies? So the user would punch in "applies from 01/01 to 31/12" and "doesn't apply from 13/07 to 16/08" and the application would display the dates as above.
– Maciej Stachowski
yesterday
add a comment |
1
Instead of a "split" button, if the exceptions are a common use case why not just keep the "add exception" button and calculate the resulting timeframes where the criterion applies? So the user would punch in "applies from 01/01 to 31/12" and "doesn't apply from 13/07 to 16/08" and the application would display the dates as above.
– Maciej Stachowski
yesterday
1
1
Instead of a "split" button, if the exceptions are a common use case why not just keep the "add exception" button and calculate the resulting timeframes where the criterion applies? So the user would punch in "applies from 01/01 to 31/12" and "doesn't apply from 13/07 to 16/08" and the application would display the dates as above.
– Maciej Stachowski
yesterday
Instead of a "split" button, if the exceptions are a common use case why not just keep the "add exception" button and calculate the resulting timeframes where the criterion applies? So the user would punch in "applies from 01/01 to 31/12" and "doesn't apply from 13/07 to 16/08" and the application would display the dates as above.
– Maciej Stachowski
yesterday
add a comment |
Overlap of rules
I apologize if I misunderstood the ASK, but I feel this is a classic case of AND & OR operations (kind of :P).
- Users add a rule (set up time period) i.e Application
- Users can add another rule on top of the above rule i.e Exception, which may or may not overlap with the set time period.
Since the application and exception are closely tied to the mental map when creating, instead of giving them separate hierarchies I feel they should have parent/child relationship.
My proposal
I love how Zapier visualizes the AND/OR operations.
In close to the above design, your interface can look like
New contributor
Could you clarify what ASK stands for?
– Lightness Races in Orbit
yesterday
Sorry for the confusion, by ASK I mean the problem statement in the question. @LightnessRacesinOrbit
– tridip1931
19 hours ago
So you mean the "question"? Not sure why this normal word was capitalised and bolded; that made it look like an acronym. Thanks for your answer!
– Lightness Races in Orbit
13 hours ago
add a comment |
Overlap of rules
I apologize if I misunderstood the ASK, but I feel this is a classic case of AND & OR operations (kind of :P).
- Users add a rule (set up time period) i.e Application
- Users can add another rule on top of the above rule i.e Exception, which may or may not overlap with the set time period.
Since the application and exception are closely tied to the mental map when creating, instead of giving them separate hierarchies I feel they should have parent/child relationship.
My proposal
I love how Zapier visualizes the AND/OR operations.
In close to the above design, your interface can look like
New contributor
Could you clarify what ASK stands for?
– Lightness Races in Orbit
yesterday
Sorry for the confusion, by ASK I mean the problem statement in the question. @LightnessRacesinOrbit
– tridip1931
19 hours ago
So you mean the "question"? Not sure why this normal word was capitalised and bolded; that made it look like an acronym. Thanks for your answer!
– Lightness Races in Orbit
13 hours ago
add a comment |
Overlap of rules
I apologize if I misunderstood the ASK, but I feel this is a classic case of AND & OR operations (kind of :P).
- Users add a rule (set up time period) i.e Application
- Users can add another rule on top of the above rule i.e Exception, which may or may not overlap with the set time period.
Since the application and exception are closely tied to the mental map when creating, instead of giving them separate hierarchies I feel they should have parent/child relationship.
My proposal
I love how Zapier visualizes the AND/OR operations.
In close to the above design, your interface can look like
New contributor
Overlap of rules
I apologize if I misunderstood the ASK, but I feel this is a classic case of AND & OR operations (kind of :P).
- Users add a rule (set up time period) i.e Application
- Users can add another rule on top of the above rule i.e Exception, which may or may not overlap with the set time period.
Since the application and exception are closely tied to the mental map when creating, instead of giving them separate hierarchies I feel they should have parent/child relationship.
My proposal
I love how Zapier visualizes the AND/OR operations.
In close to the above design, your interface can look like
New contributor
edited 11 hours ago
Prajwal Dhatwalia
1826
1826
New contributor
answered yesterday
tridip1931tridip1931
414
414
New contributor
New contributor
Could you clarify what ASK stands for?
– Lightness Races in Orbit
yesterday
Sorry for the confusion, by ASK I mean the problem statement in the question. @LightnessRacesinOrbit
– tridip1931
19 hours ago
So you mean the "question"? Not sure why this normal word was capitalised and bolded; that made it look like an acronym. Thanks for your answer!
– Lightness Races in Orbit
13 hours ago
add a comment |
Could you clarify what ASK stands for?
– Lightness Races in Orbit
yesterday
Sorry for the confusion, by ASK I mean the problem statement in the question. @LightnessRacesinOrbit
– tridip1931
19 hours ago
So you mean the "question"? Not sure why this normal word was capitalised and bolded; that made it look like an acronym. Thanks for your answer!
– Lightness Races in Orbit
13 hours ago
Could you clarify what ASK stands for?
– Lightness Races in Orbit
yesterday
Could you clarify what ASK stands for?
– Lightness Races in Orbit
yesterday
Sorry for the confusion, by ASK I mean the problem statement in the question. @LightnessRacesinOrbit
– tridip1931
19 hours ago
Sorry for the confusion, by ASK I mean the problem statement in the question. @LightnessRacesinOrbit
– tridip1931
19 hours ago
So you mean the "question"? Not sure why this normal word was capitalised and bolded; that made it look like an acronym. Thanks for your answer!
– Lightness Races in Orbit
13 hours ago
So you mean the "question"? Not sure why this normal word was capitalised and bolded; that made it look like an acronym. Thanks for your answer!
– Lightness Races in Orbit
13 hours ago
add a comment |
Instead of placing action buttons at the bottom, place "Add" buttons in each section.
Applies:
From 2019-01-01 to 2019-12-31 edit delete
+ Add
Except:
From 2019-07-14 to 2019-08-15 edit delete
+ Add
3
That would simplify things for sure, thanks. Unfortunately that wouldn't help with users being lost with the different periods definition...
– Yannick Blondeau
2 days ago
add a comment |
Instead of placing action buttons at the bottom, place "Add" buttons in each section.
Applies:
From 2019-01-01 to 2019-12-31 edit delete
+ Add
Except:
From 2019-07-14 to 2019-08-15 edit delete
+ Add
3
That would simplify things for sure, thanks. Unfortunately that wouldn't help with users being lost with the different periods definition...
– Yannick Blondeau
2 days ago
add a comment |
Instead of placing action buttons at the bottom, place "Add" buttons in each section.
Applies:
From 2019-01-01 to 2019-12-31 edit delete
+ Add
Except:
From 2019-07-14 to 2019-08-15 edit delete
+ Add
Instead of placing action buttons at the bottom, place "Add" buttons in each section.
Applies:
From 2019-01-01 to 2019-12-31 edit delete
+ Add
Except:
From 2019-07-14 to 2019-08-15 edit delete
+ Add
answered 2 days ago
Stacy HStacy H
84817
84817
3
That would simplify things for sure, thanks. Unfortunately that wouldn't help with users being lost with the different periods definition...
– Yannick Blondeau
2 days ago
add a comment |
3
That would simplify things for sure, thanks. Unfortunately that wouldn't help with users being lost with the different periods definition...
– Yannick Blondeau
2 days ago
3
3
That would simplify things for sure, thanks. Unfortunately that wouldn't help with users being lost with the different periods definition...
– Yannick Blondeau
2 days ago
That would simplify things for sure, thanks. Unfortunately that wouldn't help with users being lost with the different periods definition...
– Yannick Blondeau
2 days ago
add a comment |
Usually simplifying the copy language helps (something like "add valid time range" & "block specific dates".
A second option would be adding colors such as green (for restricted times) and red (for exception times), following the logic:
Green => go, Red =>stop
A third option is to add an icon (+ for add, - for restricting).
Best if you do all three together, this makes sure you cover more users' logics (i.e. graphic-oriented vs readers) Try to think of the user as if you were talking to a kid ;) this always helps me!
1
This is not accessible. Red-green colour blindness is prevalent (and the meaning of red/green can also differ across cultures)
– Lightness Races in Orbit
yesterday
add a comment |
Usually simplifying the copy language helps (something like "add valid time range" & "block specific dates".
A second option would be adding colors such as green (for restricted times) and red (for exception times), following the logic:
Green => go, Red =>stop
A third option is to add an icon (+ for add, - for restricting).
Best if you do all three together, this makes sure you cover more users' logics (i.e. graphic-oriented vs readers) Try to think of the user as if you were talking to a kid ;) this always helps me!
1
This is not accessible. Red-green colour blindness is prevalent (and the meaning of red/green can also differ across cultures)
– Lightness Races in Orbit
yesterday
add a comment |
Usually simplifying the copy language helps (something like "add valid time range" & "block specific dates".
A second option would be adding colors such as green (for restricted times) and red (for exception times), following the logic:
Green => go, Red =>stop
A third option is to add an icon (+ for add, - for restricting).
Best if you do all three together, this makes sure you cover more users' logics (i.e. graphic-oriented vs readers) Try to think of the user as if you were talking to a kid ;) this always helps me!
Usually simplifying the copy language helps (something like "add valid time range" & "block specific dates".
A second option would be adding colors such as green (for restricted times) and red (for exception times), following the logic:
Green => go, Red =>stop
A third option is to add an icon (+ for add, - for restricting).
Best if you do all three together, this makes sure you cover more users' logics (i.e. graphic-oriented vs readers) Try to think of the user as if you were talking to a kid ;) this always helps me!
answered 2 days ago
Andrea MaillardAndrea Maillard
312
312
1
This is not accessible. Red-green colour blindness is prevalent (and the meaning of red/green can also differ across cultures)
– Lightness Races in Orbit
yesterday
add a comment |
1
This is not accessible. Red-green colour blindness is prevalent (and the meaning of red/green can also differ across cultures)
– Lightness Races in Orbit
yesterday
1
1
This is not accessible. Red-green colour blindness is prevalent (and the meaning of red/green can also differ across cultures)
– Lightness Races in Orbit
yesterday
This is not accessible. Red-green colour blindness is prevalent (and the meaning of red/green can also differ across cultures)
– Lightness Races in Orbit
yesterday
add a comment |
The problem is that you are presenting the rules, but not the result.
As a litmus test, try to answer the question: is the criterion applied on Mar 23rd?
Instead of:
Applies from 2019-01-01 to 2019-12-31
Except from 2019-07-14 to 2019-08-15
The following display is easier to reason about... especially as exceptions pile up:
Applies from 2019-01-01 to 2019-07-13
Applies from 2019-08-16 to 2019-12-31
It could also be helpful to make this more visual. Calendars would be greatly helpful; especially with clicking to toggle on/off and SHIFT+click or CTRL+click to mass select/unselect.
If space is limited, even with text you could add extra information to help the user:
Applies from 2019-01-01 to 2019-07-13 (x days)
-- y days later --
Applies from 2019-08-16 to 2019-12-31 (z days)
This order of magnitude check can help the user identifying typos.
add a comment |
The problem is that you are presenting the rules, but not the result.
As a litmus test, try to answer the question: is the criterion applied on Mar 23rd?
Instead of:
Applies from 2019-01-01 to 2019-12-31
Except from 2019-07-14 to 2019-08-15
The following display is easier to reason about... especially as exceptions pile up:
Applies from 2019-01-01 to 2019-07-13
Applies from 2019-08-16 to 2019-12-31
It could also be helpful to make this more visual. Calendars would be greatly helpful; especially with clicking to toggle on/off and SHIFT+click or CTRL+click to mass select/unselect.
If space is limited, even with text you could add extra information to help the user:
Applies from 2019-01-01 to 2019-07-13 (x days)
-- y days later --
Applies from 2019-08-16 to 2019-12-31 (z days)
This order of magnitude check can help the user identifying typos.
add a comment |
The problem is that you are presenting the rules, but not the result.
As a litmus test, try to answer the question: is the criterion applied on Mar 23rd?
Instead of:
Applies from 2019-01-01 to 2019-12-31
Except from 2019-07-14 to 2019-08-15
The following display is easier to reason about... especially as exceptions pile up:
Applies from 2019-01-01 to 2019-07-13
Applies from 2019-08-16 to 2019-12-31
It could also be helpful to make this more visual. Calendars would be greatly helpful; especially with clicking to toggle on/off and SHIFT+click or CTRL+click to mass select/unselect.
If space is limited, even with text you could add extra information to help the user:
Applies from 2019-01-01 to 2019-07-13 (x days)
-- y days later --
Applies from 2019-08-16 to 2019-12-31 (z days)
This order of magnitude check can help the user identifying typos.
The problem is that you are presenting the rules, but not the result.
As a litmus test, try to answer the question: is the criterion applied on Mar 23rd?
Instead of:
Applies from 2019-01-01 to 2019-12-31
Except from 2019-07-14 to 2019-08-15
The following display is easier to reason about... especially as exceptions pile up:
Applies from 2019-01-01 to 2019-07-13
Applies from 2019-08-16 to 2019-12-31
It could also be helpful to make this more visual. Calendars would be greatly helpful; especially with clicking to toggle on/off and SHIFT+click or CTRL+click to mass select/unselect.
If space is limited, even with text you could add extra information to help the user:
Applies from 2019-01-01 to 2019-07-13 (x days)
-- y days later --
Applies from 2019-08-16 to 2019-12-31 (z days)
This order of magnitude check can help the user identifying typos.
answered yesterday
Matthieu M.Matthieu M.
20126
20126
add a comment |
add a comment |
Thanks for contributing an answer to User Experience Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fux.stackexchange.com%2fquestions%2f124401%2fsimplify-an-interface-for-flexibly-applying-rules-to-periods-of-time%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
what is the smallest and largest units of time here? How small can an exception be to a restriction?
– Mike M
2 days ago
1
ah okay, see my answer, i would say then you wouldn't have the 'gray' area in between it sounds like.
– Mike M
2 days ago
1
I can't edited only two characters due to low rep, but the singular of criteria is criterion.
– henning
2 days ago
1
Submitting a comment since you mentioned keeping functionality. Having "application" vs. "exclusion" doesn't seem helpful conceptually or for data entry. For example, in your criteria 3, the user must enter two date ranges (4 dates). So why not just enter the two date ranges for application: 2019/1/1 through 2019-7-14, and 2019-8-15 through 2019-12-31? If you have one range of "application" with 2 periods of "exception", this is the same thing as 3 ranges of "application." Either way, the user still has to enter 6 dates. What does the application vs. exception distinction buy you?
– Randall Stewart
2 days ago
2
What purpose do these exceptions serve? Why is it preferred to input "Applies from 2019-01-01 to 2019-12-31, except from 2019-07-14 to 2019-08-15" and not simply "Applies from 2019-01-01 to 2019-07-14 and 2019-08-15 to 2019-12-31". Same functionality, but you reduce the available inputs a lot.
– Polygnome
2 days ago