Summaries should have a word-count limit

[jwirfs-brock]

Any suggestions on length?

We could go 140 characters, to align with Twitter. I feel like for our purposes, that's a bit brief. I typically tell people "two sentences," which you can pretty safely cover with 75 words. Not sure how that translates into character count, though...

[jwirfs-brock]

The Whittier story is a good example for summary length:

The Whittier Neighborhood took control when gang issues threatened the neighborhood. Residents worked with property owners to clean up an overgrown and neglected garden where gang members had been hiding guns and drugs and start the seeds of change while creating a community garden.

It's 44 words, 240 characters (excluding spaces), 283 characters (including spaces).

[ghing]

@jwirfs-brock, We need to decide how we want to handle the limit. Do we want this to be a hard limit, that prevents the story from being saved (or maybe published) or just a counter with a warning to the user?

If it's a hard limit, does the user hit the limit when the summary is changed, or when the user tries to publish the story?

If it's a hard limit, note that users will start getting an error that they didn't see before when they re-edit their stories. I'm going to do some digging to figure out the average length of summaries.

[jwirfs-brock]

Hmm, that's a tough one. I am disinclined to do things that would cause existing users to see new errors, so it makes sense to have it be a soft limit (work count and warning) for now. I say try it, and see if it actually works. If users are still entering long summaries, we can reconsider making it a hard limit.

On Thu, Feb 7, 2013 at 7:14 AM, Geoffrey Hing notifications@github.comwrote:

@jwirfs-brock https://github.com/jwirfs-brock, We need to decide how we want to handle the limit. Do we want this to be a hard limit, that prevents the story from being saved (or maybe published) or just a counter with a warning to the user?

If it's a hard limit, does the user hit the limit when the summary is changed, or when the user tries to publish the story?

If it's a hard limit, note that users will start getting an error that they didn't see before when they re-edit their stories. I'm going to do some digging to figure out the average length of summaries.

— Reply to this email directly or view it on GitHubhttps://github.com/PitonFoundation/atlas/issues/530#issuecomment-13237354.

[ghing]

I did a quick analysis of word and character counts for published stories. These counts reflect stripping out HTML and break words on whitespace.

• Average character count: 370
• Average word count: 59
• Max character count: 2768
• Max word count: 426

If we take @jwirfs-brock's original post about 44 words/240 characters making a good summary, then:

• about 18% of the stories have summaries longer than 50 words and 10% have summaries longer than 75 words and 5% have summaries longer than 100 words.
• about 38% have summaries longer than 300 characters, 24% have summaries longer than 400 characters and 19% have summaries longer than 500 characters, and 11% have summaries longer than 600 characters.

Finally, the average word length in a summary is 5 characters.

I'd say character count is a lot easier and performant to implement than word count (especially if you want to have a running tally), but word count does a better job of capturing existing summaries. @patternleaf and @jwirfs-brock, I'll leave it up to you to work out exactly what the best summary length limit is and whether it's worth it to base it on word count rather than character count.

I'll just mention that I've never seen a running word count indicator in the wild.

[jwirfs-brock]

I think for our purposes a character counter will be ok. Let's try 250 characters and see how it goes.

On Thu, Feb 7, 2013 at 10:40 AM, Geoffrey Hing notifications@github.comwrote:

I did a quick analysis of word and character counts for published stories. These counts reflect stripping out HTML and break words on whitespace.

• Average character count: 370
• Average word count: 59
• Max character count: 2768
• Max word count: 426

If we take @jwirfs-brock https://github.com/jwirfs-brock's original post about 44 words/240 characters making a good summary, then:

• about 18% of the stories have summaries longer than 50 words and 10% have summaries longer than 75 words and 5% have summaries longer than 100 words.
• about 38% have summaries longer than 300 characters, 24% have summaries longer than 400 characters and 19% have summaries longer than 500 characters, and 11% have summaries longer than 600 characters.

Finally, the average word length in a summary is 5 characters.

I'd say character count is a lot easier and performant to implement than word count (especially if you want to have a running tally), but word count does a better job of capturing existing summaries. @patternleafhttps://github.com/patternleafand @jwirfs-brock https://github.com/jwirfs-brock, I'll leave it up to you to work out exactly what the best summary length limit is and whether it's worth it to base it on word count rather than character count.

I'll just mention that I've never seen a running word count indicator in the wild.

— Reply to this email directly or view it on GitHubhttps://github.com/PitonFoundation/atlas/issues/530#issuecomment-13249283.

[patternleaf]

@jwirfs-brock @ghing To clarify, I'm envisioning some UI on the Story Information page that has a running tally of character count with a warning when it exceeds 250 characters. And for now that's the extent of it, correct? No enforcement of this limit in the model or at display site(s)?

[jwirfs-brock]

Yes, that's right. On Feb 8, 2013 3:53 PM, "Eric Miller" notifications@github.com wrote:

@jwirfs-brock https://github.com/jwirfs-brock @ghinghttps://github.com/ghingTo clarify, I'm envisioning some UI on the Story Information page that has a running tally of character count with a warning when it exceeds 250 characters. And for now that's the extent of it, correct? No enforcement of this limit in the model or at display site(s)?

— Reply to this email directly or view it on GitHubhttps://github.com/PitonFoundation/atlas/issues/530#issuecomment-13310680..

[patternleaf]

@ghing @jwirfs-brock First pass on deploy at the moment.

One thing: the editor has an event to fire (into which we can hook to update the character count) on new words, but not on any/every change. So at the moment, the character count can be off if the editor doesn't fire its event. One option would be to update our count on a timer instead of trusting the editor. Once a second would probably be fine.

Here's a screen shot.

[ghing]

@patternleaf Can we instead listen on an event on the underlying textarea? Or, can we use events in the editor to wire up/tear down listeners to the keyUp/keyDown events for triggering the recount?

Update: I tried the current implementation and though I understand using the new word event on the editor from a cleanliness/efficiency standpoint, I feel like my expectation from using other apps is to have the character count update as I type, on each key.

[patternleaf]

@ghing from what i could tell the textarea is only updated at certain times (eg, on editor blur); not in real-time. i'll see if listening for keyup/down is easy to pull off.

[ghing]

I think I'd prefer the keyup/down solution, if it's not too painful, just because it seems more editor agnostic. If we switch editors, or get rid of the editor altogether, we'd just have to change the event that wires up/tears down the event listeners for the keyUp/down events.

[patternleaf]

actually polling strikes me as more editor-agnostic in that we have to insert keyup/down listeners at the right spot, and the right spot could change, depending on editor. so far it's looking like we will need to drill into the editor's iframe, etc ... polling is distasteful to me, but will work in any case. once per second is only mildly evil. like forgetting to bring your canvas grocery bag evil, rather than like clubbing baby seals evil. :)

[ghing]

But wouldn't we still have to listen to some editor event to turn the polling on/off?

Check out https://github.com/xing/wysihtml5/wiki/Events for a list of all the editor events. Seems like either in the case of keyUp/keyDown, there are a number of events that we could listen to to toggle the listeners.

To me it seems like we could just listen to the editor's "focus" event to turn on a keypress event listener and then listen to the editor's "blur" event to turn off the keypress event listener.

[patternleaf]

But wouldn't we still have to listen to some editor event to turn the polling on/off?

well we don't have to but we probably should. but i don't see this as the issue.

there are a number of events that we could listen to to toggle the listeners.

i'm arguing against using our own keypress listeners. if we want to use our own keypress handlers, we have to attach them to an element inside the editor's iframe. that strikes me as quite hacky and non-editor-agnostic.

[ghing]

I was thinking that we would just listen to keypress events on the window and turn the listeners on and off based on whether the editor has focus.

[patternleaf]

keypress events don't bubble up to the window when the editor has focus.

[ghing]

Looks like making these events bubble up is in the works. See https://github.com/xing/wysihtml5/pull/174. Maybe we should just poll for now and open an issue to switch to listening to keypress events once WYSIHTML5 hits version 0.5?

[ghing]

Or backport the patch in that pull request. It's really simple.

[patternleaf]

Maybe we should just poll for now and open an issue to switch to listening to keypress events once WYSIHTML5 hits version 0.5?

sounds good.

[patternleaf]

This is available for review on deploy. If there are no objections or further comments, I'll close this.