Closed Bug 507329 Opened 15 years ago Closed 15 years ago

Restrictive character limit for collection descriptions cause problems in some use cases and locales.

Categories

(addons.mozilla.org Graveyard :: Collections, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

VERIFIED WONTFIX

People

(Reporter: wis.master, Assigned: fligtar)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1

Character count is wrong when it comes to non-English
characters (eg. Korean, Chinese). To reproduce it:
1. Type some non-English characters and try to stay just within the character limits. 
2. It will fail to save when you press "submit" because it complains I'm over the limit. 

I realise the description field is a brief summary of the collection. However character limit in Add-on Collection is too restrictive in a way that we can't even briefly describe what the add-on collection. Character limit is also too restrictive for non-English description (only 1 sentence is possible!!).

Change it into 1000 or 1500 characters please!

Reproducible: Always
This is site related, as no descriptions can be added in the Collector.

I suspect it is a dupe, cc'ing some folks possibly in the know.
Summary: Add-On Collector: Character count and limit bugs → Collections: Character count and limit bugs
hm, is the check possibly not using mb_strlen? Don't think it's a dupe then.
The cause of this might be the same as that of bug 503502.
(In reply to comment #1)
> This is site related, as no descriptions can be added in the Collector.
> 
> I suspect it is a dupe, cc'ing some folks possibly in the know.

Yes but on the Manage Collection pages. I'm not sure if it should be still classified under "Products: addons.mozilla.org Component: Collection" though. Feel free to change it if I'm wrong.

(In reply to comment #3)
> The cause of this might be the same as that of bug 503502.

No it's not the same. The OP complains why one-character word is disallowed as a tag. AMO has min-character requirement for tags. It makes sense in English but not in other languages. This has nothing to do with Add-On Collector (and its related pages on the site).

A quick solution, and actually I think you should do it anyway, is to raise the character limit to 1000 (or 1500) characters. At least it can solve problems faced by people using other languages.

In fact what is the logic behind of picking 200 characters as the max limit? Why 200? What justifies it? I realize this field is used as a brief summary or introduction only I'm not writing an essay in it. But it's far too restrictive.

I have been browsing in other sites which ask you to submit your news or entries and requires you to fill in short descriptions. The limit ranges from 500-2000. Hard disk space is cheap nowadays. I believe even 2000 characters only waste far less than 1MB.
(In reply to comment #2)
> hm, is the check possibly not using mb_strlen? Don't think it's a dupe then.

Using mb_strlen alone may not fix the problem.  See bug 503520 and bug 503502 comment 1.

(In reply to comment #4)
> (In reply to comment #3)
> > The cause of this might be the same as that of bug 503502.
> 
> No it's not the same. The OP complains why one-character word is disallowed as
> a tag. AMO has min-character requirement for tags. It makes sense in English
> but not in other languages. This has nothing to do with Add-On Collector (and
> its related pages on the site).

I am not saying that this is a duplicate of bug 503502.  But anyway, bug 503520 and bug 503523 turned out to be better references than 503502.

> A quick solution, and actually I think you should do it anyway, is to raise the
> character limit to 1000 (or 1500) characters. At least it can solve problems
> faced by people using other languages.

How many actual characters do you want to write in the summary, and in which language?  In Korean and Chinese, most characters take only 3 bytes in UTF-8, and 1000 bytes in UTF-8 sounds too long in these languages.  I do not claim that 200 bytes is sufficient, but 1000 bytes sounds like the other end of the extreme as long as Korean and Chinese are concerned.  (Disclaimer: I do not read Korean or Chinese.)
What about Arabic? How many bytes does each character occupy?

We should accommodate all users around the world who speak different languages so we should be lenient about our limit. Unless there are some barriers or technical limits that I'm unaware (eg. higher limit will make the site malfunction), it doesn't hurt anyone to be lenient, does it? Let them say some more if they want to give us a better introduction of their collections. 

A short paragraph in Korean or Chinese (similar to your last paragraph) should easily bypass 600-700 bytes. Basically I would like to tell my users about these aspects of my collection:
- What is this collection about? (2-3 sentence)
- What does this collection target for? (1-2 sentence) 
- How do I pick addons, ie. the inclusion requirements of this collection? (2-4 sentences, useful for collaborative management)
- Leave an URL to my webpage, if any (a personal webpage which describes my collections)
(In reply to comment #6)
> What about Arabic? How many bytes does each character occupy?

As I said, we need to not count bytes, but characters.
This isn't about the cost of storing extra characters - it's about being concise in your collection description and having that description fit everywhere it needs to fit. The collection description isn't just displayed in the big area on the collection page - it's in several other smaller areas.

We should definitely fix the character counting of multi-byte characters to match 200, but I'm not ready to increase the limit.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #6)
> A short paragraph in Korean or Chinese (similar to your last paragraph) should
> easily bypass 600-700 bytes. Basically I would like to tell my users about
> these aspects of my collection:
> - What is this collection about? (2-3 sentence)
> - What does this collection target for? (1-2 sentence) 
> - How do I pick addons, ie. the inclusion requirements of this collection? (2-4
> sentences, useful for collaborative management)
> - Leave an URL to my webpage, if any (a personal webpage which describes my
> collections)

That sounds like more than 200 *characters*.  Let me break down the problem which you want fixed into two:
1. The length limit is currently counted in bytes, but should be counted in characters.
2. The length limit of 200 characters is too short for the description of a collection.
Is this correct?

Item 1 is clearly a bug, and I think that everyone agrees that it should be fixed.  If I am not mistaken, it is part of bug 503520 and/or bug 503523, as I wrote in comment 5.

Not everyone has agreed that item 2 should be fixed.
(In reply to comment #7)
> As I said, we need to not count bytes, but characters.

Yes if it could be fixed in reasonable time.
Otherwise raising the limit is an easy and fast way to fix the problems people have been facing now.
(In reply to comment #8)
> This isn't about the cost of storing extra characters - it's about being
> concise in your collection description and having that description fit
> everywhere it needs to fit. The collection description isn't just displayed in
> the big area on the collection page - it's in several other smaller areas.

What does it mean? Is it a standard you want to promote, or everyone who use it must adhere to it?

If it's a standard, why do you think it's always a good idea in nearly all, if not all, use cases? Why don't we try our best to cater all users with different needs? Different people may have *very* different needs and have a very different definition of "concise" and what should be included in a "brief description".

You define 200 characters as "concise". Why is it 200 characters in the first place? Did you do any research before you set this limit, in other words, what facts or evidence justify that 200 characters is a good threshold which can fit in all use cases of all languages?

I would say there is no one-size-fit-all. The advantage of setting a less restrictive limit:
(1) cater more people with different needs (not all people agree with your definition. Why not if they want to write more?)
(2) more resistant to error (like this incident. It doesn't cause much of a problem if you set it 1000 characters even if you have bugs in counting multi-byte characters) 
(3) more leeway and easier to deal with all languages, even those you know very little (Different languages have very different structures. You think it's adequate in your language doesn't mean it's also adequate in other languages. 
Some languages use more characters to say the same thing, some less.)

Now it's your turn to tell me the problems of setting a less restrictive limit. Why not relaxing the limit a bit to make more users happy if there is no technical barrier to change the limit?

If there is a technical problem to display a larger block of description (you did mention it is displayed in several small areas too), there are several ways to solve it apart from placing a hard limit universally.

Truncation - Descriptions in small areas will be truncated if over 200 characters (line or space occupied count, if technically possible, is a better measure than characters because some languages like Chinese is very compact and occupies much less space than English). 

Tooltip - [Optional] Mouseover on the compact description. A tooltip will pop up and displays the full description

Expansion - [Optional] Click to expand the description.


Display areas can be solved without placing a hard limit. So what else stop you from relaxing the limit and making more users happy?
(In reply to comment #9)
> That sounds like more than 200 *characters*. 
Well 200 characters is okay. Chinese doesn't use space to separate words so it helps to keep within limit. Korean uses space as a separator and it uses more characters to convey the same message than Chinese. For example it takes me 355 characters (without counting space) and 434 (with space) to translate it into Korean.

Show a little compassion on users who have to use many characters to say the same things. ;-)

> Let me break down the problem which you want fixed into two:
> 1. The length limit is currently counted in bytes, but should be counted in
> characters.

Yes it would be better. :-D

> 2. The length limit of 200 characters is too short for the description of a
> collection.
> Is this correct?

Yes or no. See above.

OK here is another use case that people may want to describe things that you may have never thought of. Let's say I want to create a public collection. Okay, first of all, you should put a nice description to tell people what your collection is about. You want to take your collection to the top of most popular list too. You want to say a bit more how special your collection is and how it differs from others, or you are going to lose. 

Your collection is open for anyone to manage and publish addons too. You at least need to tell other about your intention and write a welcome message to invite people to join you. Moreover you need leave your contact email or website (if any) for people who are interested to contact you.

All those messages and information are essential. How are you going to put it in a way which doesn't run over the limit of 200 characters? Impossible!

> Item 1 is clearly a bug, and I think that everyone agrees that it should be
> fixed.  If I am not mistaken, it is part of bug 503520 and/or bug 503523, as I
> wrote in comment 5.

Yes that would be great. But how long do you guess it takes to fix that bug? [My feeling only!] I feel it's a hard bug to fix which seems to take several months, if not a year, to fix it. 

Why not just raise the limit while you are fixing this bug? Don't forget it doesn't hurt to relax the limit after all. You won't be worse off because you can describe your collection in 200 characters when the limit has increased to 800 characters.

By the way don't forget to fix non-English punctuations too (eg. ?!、,。).

> Not everyone has agreed that item 2 should be fixed.

Well it depends on your goal. If you want to make decisions on others and tell them how much they must write in the description, you can set it as the only standard and ask anyone to follow. You don't need to fix it.

If you treat it's a tool which helps people and fulfil their needs, we should try our best to satisfy as many people and as many different needs as possible. As you see there are some use cases where a less restrictive limit is clearly beneficial. Why not increase it even if you personally don't need? You do realize some others want more, don't you?

I don't add more than 10 addons per collection. I will split if it's over the limit. I think it's more concise and organized in this way. But I won't force everyone to follow me, even less going too far to set a hard limit of max 10 addons per collection.

I like to let people choose. Freedom of choices. That's me. ;-)
The current discussion does not seem to go anywhere.  In my opinion, we should either split this bug into two, or just concentrate on the request of enhancement to increase the limit of the number of *characters* from 200 (assuming the other part is included in bug 503520 and/or bug 503523).  See my comment 9.
Blocks: 507834
(In reply to comment #13)
> The current discussion does not seem to go anywhere.  In my opinion, we should
> either split this bug into two, or just concentrate on the request of
> enhancement to increase the limit of the number of *characters* from 200
> (assuming the other part is included in bug 503520 and/or bug 503523).  See my
> comment 9.

Done: bug 507834

Yes, one bug per report. Morphing this one to be explicitly a request for a raise in limit for all locales.

I wouldn't be against raising things to 250 myself, but I agree with the intent here to keep things short. Truncation looks stupid and if we just force people to describe their collection simply it shouldn't be needed. What you really want is bug 498088.
Severity: normal → enhancement
OS: Windows XP → All
Hardware: x86 → All
Summary: Collections: Character count and limit bugs → Requesting a raise in the character limit for collection descriptions
@Dave: Thanks both for splitting a new bug and for morphing this bug!
Summary: Requesting a raise in the character limit for collection descriptions → Restrictive character limit for collection descriptions cause problems in some use cases and locales.
So about 5 bug submissions have been raised which stem from this restrictive limit: Bug 498088, Bug 507329, Bug 507834, Bug 503520 and Bug 503523.

In fact any solution is okay as long as it can solve the problems some people facing in some use cases or when using some languages. However most of the suggested solution, as I observe, is not easy to fix. It may take even a year or several to fix all bugs relating to the restrictive limit.

So it's kinda stupid to make users wait so long just to type some more texts, waiting so long just to fix a problem caused by a limit arbitrarily set in the first place, not to say we already have an easy fix readily available **now** which can make more users happy **now**.

Relaxing the limit is the only solution so far which can solve the problem in a timely manner. We can always adjust again later when other bugs and issues have been fixed/addressed.

There are much whitespace in the collections page. The right column (the one with XX add-ons, XX subscribers) has much whitespace so you can move a bit towards the end. The big column with "What are Collections?" and "Add-on Collector" can be shrunk a bit. The large empty space at the edge can be shrunk a bit too. 

450 characters takes 5 lines (or 4 lines if you have better use of empty whitespaces) and it's still appropriately placed within the small display area.
700 characters takes 7 lines (or 6 lines with better use of whitespaces). You may use a sightly smaller font size to help a bit too.

Don't lock yourself into 200 character limit dilemma. 200 isn't a well-thought-out number and may be arbitrarily set in the first place. We have yet to see any findings or supporting reasons to explain why 200 is the golden and right number. Don't assume the number is right and is reluctant to make changes simply because it's there on day one!!

It's **ACTUALLY FINE** to raise the limit to 400-500 characters. Relaxing the limit ** WON'T MAKE ** the page look so bad! Please download the page and try it yourself. Play around it and witness by your eyes. Nothing bad happens when you raise the limit to 450 (or even 700 if you tweak the page layout).
(In reply to comment #16)
> So about 5 bug submissions have been raised which stem from this restrictive
> limit: Bug 498088, Bug 507329, Bug 507834, Bug 503520 and Bug 503523.

No.  The essence of neither bug 503520 nor bug 503523 has anything to do with collections.  These two bugs apply to many things in AMO, possibly including collection descriptions.  That’s all.

Bug 498088, bug 507834 and this bug might be worked around if we raise the limit from the current 200 bytes to 1000 bytes (say), but that is not the right solution, just a workaround.  Honestly speaking, I do not think that any of these three bugs is important enough to employ a workaround hastily.
(In reply to comment #16)
> So about 5 bug submissions have been raised which stem from this restrictive
> limit: Bug 498088, Bug 507329, Bug 507834, Bug 503520 and Bug 503523.

I filed bug 498088 essentially as the *opposite* of this bug. A short limit for a short description is correct. If people want more there should be a space for more, not just fill up a short description.

@Morlan: Saying your view more and louder does not make it more likely to be accepted. Do not post complaints about the same thing to multiple bugs like you have. When you do post, you also need to learn to be more concise.
(In reply to comment #17)
> Honestly speaking, I do not think that any of
> these three bugs is important enough to employ a workaround hastily.

Thinking it in another way round, I do not think employing a "workaround" will cause any serious or big problem either. So would you mind explaining why the issue must be important before you can relax the limit? Why so reluctant in relaxing the limit a bit?
(In reply to comment #18)
> A short limit for a short description is correct. 

In case if you miss it, I agree a short limit for a short description. But here comes another question - why do you think 200 character is the right number? "Short limit for short description" has nothing to do to justify that the number must be 200.

To prevent the discussion wandering around and arguing things which we may actually agree, let's try to keep the focus and define the actual problem area.

First of all I pointed out the limit has some problems and 200 isn't the right number. To solve all the problems associated with the limit (some caused by bugs which are hard to fix) I suggested relaxing the limit. I suggested 1000 bytes.

Then someone pointed out that 1000 bytes may not be possible because "The collection description isn't just displayed in the big area on the collection page". We have to consider the display in small areas too.

"Short" is a vague and relative term. Let's define what is regarded as a good "short". The description is regarded "short" if it still fits inside the display of small areas. Are you with me at this point?

The best way to find out the optimal value, in my opinion, is to try it out and witness yourself.

fcp or Dave Garrett, have you ever tried to test/simulate it to see how the page looks after an increase in limit? Add more texts bit by bit. Stop until you reach the point more texts will break the layout or make the page look ugly. 

It's hard to visualize the whole scene by words only. Please spend a little time to try it yourself. I believe you will agree with me.

> When you do post, you also need to learn to be more concise.

I don't know if it's you who tell me. But it's said I should post strictly one bug per post. Sometimes I want to group very similar bugs together and post as one in order to make the post concise, but you told me it is a bad idea. So I "split hairs" even if bugs are overlapping with each other.

I do see some people would post something like for the record here's the relevant parts in bug ABC: <quote the message>. I think it's the side-effect of "splitting hairs".
(In reply to comment #20)
> > When you do post, you also need to learn to be more concise.
> 
> [...] But it's said I should post strictly one bug per post.

Dave meant, you should make shorter comments and not repeat yourself as often. He was not advising against several bugs for several, different, issues.

This bug is about increasing the character limit on collection descriptions (unlike bug 507834). You have stated the reasons why you think this should happen, and others have argued that a very concise, 200-character description is actually a good thing. The decision hasn't been made yet on if it will be increased or not.
Judging from comment 8 this is a wontfix, but ->fligtar for final call.
Assignee: nobody → fligtar
I don't want to increase the limit of this field for the reasons I mentioned in comment 8. bug 498088 calls for an additional field that can be much longer and contain as much information as needed, just like we do with add-on listings. I support that idea, but it's not a high priority (not going to be fixed immediately).
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
(In reply to comment #21)
> 
> This bug is about increasing the character limit on collection descriptions
> (unlike bug 507834). You have stated the reasons why you think this should
> happen

After all you have to remember that the bug has been morphed so the discussion might look inconsistent. I don't really agree on how it's morphed but I'm not going to argue about it.

> and others have argued that a very concise, 200-character description
> is actually a good thing. The decision hasn't been made yet on if it will be
> increased or not.

Well nearly none of the questions/issues/other suggestions (#11, #12, #19, #20) get any response and are automatically refuted out of the blue. Forget what I said/doubted anyway, see what you all say.

If I understand all of you correctly this is how you justify 200 limit:

1) The description has to be short because it has to display in small areas  (#22: Judging from comment 8...)
2) So 200 limit is actually a good thing and shouldn't be changed

Well the reasoning is clearly flawed. No one seems to care to get it or they just want to turn blind eyes on it. The exact same reasoning can be used to argue for a different number:
1) The description has to be short because it has to display in small areas 
2) So 300 limit is actually a good thing and shouldn't be changed

So another argument:
1) The description has to be short because it has to display in small areas 
2) So 400 limit is actually a good thing and shouldn't be changed

You guys keep using the same invalid reason to support your flawed conclusion. It's not a debate whether the description should be long or short. I do agree the description should be short after Comment #8.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
My doubt is why you all take it for grant that 200 is the right and golden number in the first place. Why can't you cast even the slightest doubts and reconsider the optimal limit (balance is the key: number of situations solved vs space of display area)?

I'm actually the only one who spends time to test how the description looks in the small area when the limit becomes 200 vs 300 vs 400 and so on. It's at least a better and less subjective way than your holy and blind faith on golden 200. Clearly there is room for increase EVEN THE DISPLAY AREA IS SMALL but this fact is blindly ignored.

Answer those questions please. Even yes or no is fine:
1) Have you ever tested how the page looks when the limit becomes 200 vs 300 vs 400 and so on?
2) If so how many characters did you manage to add before the page looks bad or the display areas looks too crowded?

What are your grounds to deny the fix?
3) Limit can't be raised by any extent, no matter how small it is (be it +100, +50, or even +20). Yes or no?
4) The choice of number 200 is taken for grant for no particular supporting reasons. This number must be right. Yes or no?

Finally and most importantly
5) Why did you set it as 200 in the first place? What reasons do you have to support 200 (but not 250, 300, 350, 400, 450, 500 and so on)? Do you really have valid reasons for the choice of 200? Yes or no?

Read the summary again: Restrictive character limit for collection descriptions cause problems in some use cases and locales.

The problem still exists. You just deny the suggestion of one of my fixes without giving any valid reason (to justify your number), or discussing related/relevant solution not appearing in any bug.
(In reply to comment #24)
> If I understand all of you correctly this is how you justify 200 limit:
> 
> 1) The description has to be short because it has to display in small areas 
> (#22: Judging from comment 8...)
> 2) So 200 limit is actually a good thing and shouldn't be changed

Clearly you don't understand this correctly. Read comment 8 more carefully.

(In comment #8)
> This isn't about the cost of storing extra characters - it's about being
> concise in your collection description and having that description fit
> everywhere it needs to fit. The collection description isn't just displayed in
> the big area on the collection page - it's in several other smaller areas.

Whether or not it "looks fine" on the page is largely irrelevant. There are other smaller areas it needs to show.

Secondly, the big point here that is clearly lost on you: We want a very short limit to force users to be concise and to the point. We want simple descriptions so when people are browsing through them they don't have to read War and Peace. Most people are not very concise unless forced. (I'm aware of the irony in this context; you are not) For people who really do need more info, there's bug 498088.

This bug was marked WONTFIX by a person who gets to make those decisions. You, Morlan, are not that person. Please do not abuse this system and leave the status alone. Please also stop posting long comments in multiple bugs about this issue. We know exactly what your view is and more text does not help. Please stop.
Status: REOPENED → RESOLVED
Closed: 15 years ago15 years ago
Resolution: --- → WONTFIX
I do not understand what you are talking about the last paragraph and I HAVE NOT abused the system. At least it's never my intention although I may did something wrong in between. I take it as an insult and as a way to win arguments by making personal attack. Please don't bark up the wrong tree. There is something wrong if it did happen. Sorry in advance. Please stop any personal attack.


Well, simply put, just say 200 is taken for grant and it must be the right number. Thus it is not changeable.

First point, you haven't clarified what other small areas you have to show. From the wording it shows how you want to hastily assume 200 is right.

Second point, short / concise / to the point etc. (again!) only says it should be a short limit but has nothing to do to justify why 200 is the right number. You are merely begging the question. I wonder what you would say when 300 was set initially. You would again argue all your way to justify why 300 was right. Well I wish there were a time machine.

+100 is about 1 sentence more as a matter of fact. Copy and paste my first sentence if you don't believe it. Basically they are suggesting that 1 sentence more would fail to meet the criteria of "simple descriptions". They want to make you believe that adding 1 or 2 sentences more make such a big difference.

How "concise" and "good" the description is when there are several collections of the same kind available and you want to use 1-2 sentence to describe the difference but you find you couldn't.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
I think you (or the person in charge) should be frank if you simply want to set it at 200 arbitrarily for personal liking. I don't mind if you say explicitly so in the first place. After all it's your product. It's perfectly fine to be close-minded (no offense!). But please don't pretend you have strong reasons to support though. 

PS: I gladly challenge you if you clearly believe you have logically strong reasons to justify 200. Well, we can present our arguments in logic forums and let the third party judge, but I don't think you will bother. ;P
Morlan: Please read the bugzilla etiquette, particularly point 2.2.

https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
Status: REOPENED → RESOLVED
Closed: 15 years ago15 years ago
Resolution: --- → WONTFIX
We are not raising the limit, and if you want to believe it's for my personal liking, go ahead.

If you re-open this bug again, I will request that your account be disabled.
Application refused.
Status: RESOLVED → VERIFIED
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.