Edit box for quick reply posting.
Straight_Man
Geeky, in my own wayNaples, FL Icrontian
I am not complaining, simply observing two things:
First, at the character sizes I need to use to see, the quick reply input\edit box is too narrow a character width. The full edit input\edit box in the online editor is fine.
Second, when the server is busy, the qucik reply editor drops one character as it wraps if one does not pause entry as it wraps. I've seen it do this with as few as 10-12 users online at once, and it might relate to how many folks are using the quick reply function also. The full function input\edit reply box handling does not have this problem. The full reply editor also does not seem to scramble characters resulting in things like 'adn' and takes input faster.
Is there a resource priority parm for the quick reply box that can be increased 10-25% and give a more balanced response as the code is probably similar for the box handling itself and I think this is a tuning thing that should be tweakable. If the box for quick reply would stretch vertically some that would also help, but making it wider would in fact also eliminate the fact that when the quick reply box spawns and uses the scroll bar on client end and then the scrollbar is used the number of lines in box determines scroll accelleration in two browsers (Opera and Netscape) on my boxes here.
IF could be widened it would be more usable, wrap less often and not drop characters as much, and if it could be made floating length or taller the scroll accelleration would vaporize for some larger posts. If, since a lot of folks have said they use it, the priority for the quick reply box handling code could be increased, the replies would be handled faster in at least editing and lost chars in buffer would be diminished also. WISH LIST things, not immediate need, but I am trying to pinpoint wish list things here that would encourage thread replies.
No, not mostly keyboard or user only on client end as can replicate on multiple browsers, boxes, and O\S families and also multiple different keyboards on each.
John.
First, at the character sizes I need to use to see, the quick reply input\edit box is too narrow a character width. The full edit input\edit box in the online editor is fine.
Second, when the server is busy, the qucik reply editor drops one character as it wraps if one does not pause entry as it wraps. I've seen it do this with as few as 10-12 users online at once, and it might relate to how many folks are using the quick reply function also. The full function input\edit reply box handling does not have this problem. The full reply editor also does not seem to scramble characters resulting in things like 'adn' and takes input faster.
Is there a resource priority parm for the quick reply box that can be increased 10-25% and give a more balanced response as the code is probably similar for the box handling itself and I think this is a tuning thing that should be tweakable. If the box for quick reply would stretch vertically some that would also help, but making it wider would in fact also eliminate the fact that when the quick reply box spawns and uses the scroll bar on client end and then the scrollbar is used the number of lines in box determines scroll accelleration in two browsers (Opera and Netscape) on my boxes here.
IF could be widened it would be more usable, wrap less often and not drop characters as much, and if it could be made floating length or taller the scroll accelleration would vaporize for some larger posts. If, since a lot of folks have said they use it, the priority for the quick reply box handling code could be increased, the replies would be handled faster in at least editing and lost chars in buffer would be diminished also. WISH LIST things, not immediate need, but I am trying to pinpoint wish list things here that would encourage thread replies.
No, not mostly keyboard or user only on client end as can replicate on multiple browsers, boxes, and O\S families and also multiple different keyboards on each.
John.
0
Comments
When the server is busy, I have noticed short thread replies post notably faster than when replies to long (large in data content) threads are posted, too. Since the quick reply box is used a LOT proportionately, if the priority for handling replies could be increased and the new post slightly decreased, even in the DB handling, some things that are being seen now would vaporize massively.
If I post with no graphics shown as graphics signatures defaulted, the quick reply and new post boxes both function faster and more responsively. This is overall, and nice-- if the server can feed less graphics overall, it has more residual time to feed and hanlel text I\O and this server is fast and responsive. But the "quick reply" function seems to be deprioritized a bit also, in proportion to the new post handling when one considers its popularity versus the new post editor. The quick reply form could also be more like the full ("new") editor in the aspect of stretching vertically, possibly.
One VERY quick possible fix-- use the full editor for all replies AND new posts. Then we can both see if it is also a priority from module to module thing and measure how much time is spent handling posts themselves from timestamped logs if the loggs can show posting handling as time to begin and end post session and how many posts are made at what hours GMT wise would also help determine peaks and proportionate time used.
John.
The reason why the full reply is longer in posting is due to the fullness of it's posted information. When the HTML form passes variables to the PHP page using quick reply, some values are already predetermined (and are invisible to the end user). With the "normal" reply, these variables are determined by the enduser
The difference is simple really. The quick reply was designed for the purpose laid out.. ie.. quick reply. A quick and dirty way to answer a thread
I will quite happily look at increasing the width of the quick reply and quick PM boxes, I will admit they are a little small, but then they are designed to be quick!
Consider the two. The quick reply does not have the ability to quote or mulitquote. It does not parse clickable smilies (you have to insert those yourself). I have hand coded signature, email reply and attachment functions in to make it more usable. However, it is as it says it is.
Quick reply
Il extend the width, but the consensus is that making the box larger to accomadate other full reply functions AND adding the ability to drop quotes into it from other posts.. defeats the object
The speed issue is an unrelated matter. Sadly, a quick installation of a frontpage CMS has dragged the site speed down. We have never denied we have a code issue with it. It has served it's purpose but will be shortly replaced by a considerably more stable and efficent CMS. This will bring the site to its full potential and annihiliate any instability or speed issues.
But as certain members have signatures that force horizontal scrollbars even at 1024 then you may as well go and fill the whole screen at 1024 with it.
NS
I cannot speak for Ageek, but I can definitely speak for myself (yes, I know, it is a trick I have been working on for years, but I've finally been able to figure out how to speak for myself).
I don't want a full-sized quick-reply box. I just want a textarea box (be it quicky-reply, regular reply, initial post, whatever) to be full-width. Meaning, taking up all of the frame it is contained inside, or at least 80-90% of that frame.
Making the attachment textarea longer would be nice too, since most paths are much longer than the visible characters.
If it benefits the site, I'm sure Shorty will add it when he has the time. No rush on my part. I've been content up 'til now and I'll be content if it never is implemented.
As for adding the ability to click on smiles, etc. to put into a quick-reply box.
Nah! I agree with Shorty, that defeats the purpose of quick-reply.
Shorty's done great so far and I have confidence he'll continue to do great.
Textboxes in HTML are a specified size. They don't have a variable width. I will make it to fit a 600x800 window but anymore and we risk strange showthread.php problems.
Il work on it after the weekend, Im currently integrating our new CMS into VBulletin. Give me time to finish the mass of code changes Im working out to make it work
now i hope all that made some form of sense
I thought of the click a link to open a pop-up window, but I'm not deft with HTML so I don't know how to make one window send information to another window's textarea so since I didn't think it was something that could be easily coded, I didn't mention it. Shorty already has a lot he does.
Of course . . . if you're up to it, Shorty, feel free to implement that too.
Why are the text input boxes (both quick and regular reply) so small in Netscape v7.1 compared to IE? (About 60% of the width)
The way the browswer interprates code optimised for IE. There is a tweak option in the backend. I've tweaked it a little, let me know if it's improved
MUCH Better!
I don't know if that's possible or not, but if the screen width can be gotten (which I know it can if JavaScript is enabled on the browser) then cannot the frame width be gotten?
Anyway, just a thought.
Thanks for the wider text box, Shorty! This is much nicer!