members icon indicating copy to clipboard operation
members copied to clipboard

Activation Code Expiry UI

Open simoneeconomo opened this issue 13 years ago • 20 comments

Is it necessary to have words like "hour" or "hours" (or "minutes" and so on...) inside the text input? What happens if someone accidentally writes "48 hour" instead of "48 hours"? I'm just not sure that is the more robust way to customize the expiry. Any comments?

simoneeconomo avatar May 27 '11 20:05 simoneeconomo

I disagree and think it is the most robust way as it gives the developer complete control. Having some set values will always come back to a situation that requires something unique, which would require changing of the extension code. Given how often this setting has to be set, and the fact its done by a dev and not an author, I'm happy to leave it as.

brendo avatar May 28 '11 01:05 brendo

Having some set values will always come back to a situation that requires something unique, which would require changing of the extension code.

There are many other ways to ensure unique values, without relying on words that: a) could be mistyped, thus affecting the expected behaviour; b) will require translation in other languages, so to conform with the rest of the backend.

Given how often this setting has to be set, and the fact its done by a dev and not an author

Authors can mistype words too. ;) Moreover, in order for a system to work predictably, users should be able to foresee what happens if they break the rules. In fact:

What happens if someone accidentally writes "48 hour" instead of "48 hours"?

I'm not able to answer to this question. I can imagine "hour" won't be recognised as it's related to the value "1", but then which is the default value? Will an error be thrown upon saving instead? Looks like this extension still needs to explain a lot that should be clear by using its UI.

simoneeconomo avatar May 28 '11 09:05 simoneeconomo

There are many other ways to ensure unique values

Oh, I didn't mean unique as in only one, I meant if we just make a select box and have 1 hour, 2 hours, 1 day etc, there will be a use case where someone needs to have the code expire in 6 hours. This was a complaint from the first Members extension that the code was locked to 2 weeks expiry (and it often comes up now about the Cookie expiry too)

What happens if someone accidentally writes "48 hour" instead of "48 hours"?

The same result, strtotime returns the correct result if a user misses the 's'.

Looks like this extension still needs to explain a lot that should be clear by using its UI.

I thought the current approach was consistent with Symphony's UX. Open to your ideas though

brendo avatar May 28 '11 11:05 brendo

An idea could be an input field for numeric values plus a selectbox with the following options: "minutes / hours / days / etc." This should ensure the same flexibility as the current approach, but avoids the confusion of having an input field that forces one to adhere to a particular syntax.

simoneeconomo avatar May 28 '11 11:05 simoneeconomo

Any news on this? While I know it's too late for Members 1.0 I'd like to discuss different approaches (like mine) for Members 1.1.

simoneeconomo avatar May 30 '11 12:05 simoneeconomo

IMO it's a downgrade in functionality, but sure, we can discuss and gauge feedback from the 1.0 release.

brendo avatar May 30 '11 13:05 brendo

Just to clarify: there's no downgrade in functionality as the flexibility remains the same. The only differences between the current approach (taglist-like) and the one I proposed (input field + selectbox) are:

  • You don't have to type "hours" or "minutes" or "days" etc., as these values are available in the selectbox.
  • The interface becomes translatable, while the current approach makes it difficult to translate keywords like "hours" etc.
  • Users are less prone to errors, as they only need to type numbers (thus, no typos)

simoneeconomo avatar May 30 '11 13:05 simoneeconomo

Simone, it’s evident that you feel very strongly about this. If you are happy enough to make the change, I’m sure Brendan will be more than happy to merge the change in when the extension updates next.

allen avatar May 30 '11 19:05 allen

What happens if you need to mix days, hours, and minutes? Like if you want to set it to 2 days, 6 hours, and 45 minutes?

cz avatar May 30 '11 19:05 cz

Then we need a better alternative because mine didn't take mixes into account. The underlying problem still remains, though.

simoneeconomo avatar May 30 '11 19:05 simoneeconomo

The underlying problem still remains, though.

As an example, I accidentally wrote "24 hours 1 hour 45 minutes" (I thought I typed "24 days") and no errors were thrown. What happened? Which is the computed value? 25 hours, 1 hour? And so on...

simoneeconomo avatar May 30 '11 19:05 simoneeconomo

How about a text input with autocomplete for keywords? On May 30, 2011 3:52 PM, "eKoeS" < [email protected]> wrote:

The underlying problem still remains, though.

As an example, I accidentally wrote "24 hours 1 hour 45 minutes" and no errors were thrown. What happened? Which is the computed value? 25 hours, 1 hour? And so on...

Reply to this email directly or view it on GitHub: https://github.com/symphonycms/members/issues/151#comment_1263262

cz avatar May 30 '11 20:05 cz

I think we're over engineering the problem here.

If we want to eliminate potential user error and keep a simple enough interface, then we just need to maintain a single unit of time measurement, rather than supporting a range.

Bear in mind that 1 day == 24 hours == 1440 minutes. The lower the denominator, the more precise you can make your measurement.

Next we look at the actual purpose of the field. We're talking about activation expiry time. In my opinion, the most common range should fall between an hour to a day. Any less than an hour, then you're not giving enough time for the user to respond and take action. Any more than a day then you're defeating the purpose of having a code expiry to combat brute-force exploits.

If a user want values outside of the bell curve (80/20 philosophy), it's still possible. 30 minutes can be represented by 0.5 hours. A week is 168 hours.

allen avatar May 30 '11 21:05 allen

Thanks for your replies.

we look at the actual purpose of the field. We're talking about activation expiry time. In my opinion, the most common range should fall between an hour to a day. Any less than an hour, then you're not giving enough time for the user to respond and take action. Any more than a day then you're defeating the purpose of having a code expiry to combat brute-force exploits.

I admit I was a bit afraid of talking about real-life values 'cause someone could argue that it's not the Symphony way, but what Allen says is exactly what I thought. Better than an input plus a selectbox is an input and a single unit of time. Using hours means that minutes are difficult to target (30 minutes = 0.5 hours, but 20 minutes = 0.333 hours!). At the same time this is also educative: bizarre values other than "30 mins" shouldn't be encouraged.

On the other hand if we want more flexibility, then using minutes is the right choice. We're going to get really high values (e.g. 1440 minutes for 1 day, as Allen said), but it's a good compromise in my opinion.

simoneeconomo avatar May 30 '11 22:05 simoneeconomo

If we look at the Dynamic XML DS and the Youtube/Vimeo fields, they have expiry times which are all reflected as a input field for the number of minutes, perhaps this should be considered?

brendo avatar May 30 '11 23:05 brendo

Okay, I'm good with that. I'd vote for consistency in this instance and go with 'minutes' as the standard unit.

allen avatar May 31 '11 00:05 allen

Brendan, if you are too busy I can submit a pull request with the mentioned changes. Just let me know.

simoneeconomo avatar May 31 '11 10:05 simoneeconomo

Go for it, reckon you can get them in the next 12 hours?

We can push back 1.0 for a day or so while @michael-e and @hypnosis update the translation to include the copy changes.

There will need to be updater logic to convert the current expiry text to minutes, (although I think the database should still store it as '30 minutes' rather than just '30'

brendo avatar May 31 '11 11:05 brendo

Yikes, I don't think I have enough time today. If there's time to include this change in Members 1.0, then I think it's better if you make these changes yourself. Otherwise, if this stuff goes in Members 1.1, I can save you some time and send a patch.

simoneeconomo avatar May 31 '11 11:05 simoneeconomo

Okay, I think I've got almost everything working, except for the update script that doesn't seem to be executed. Shouldn't the following condition suffice?

Edit: never mind, shame on me!

simoneeconomo avatar Jun 08 '11 21:06 simoneeconomo