Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Arantor
1576
Features / Multiquote
« on February 16th, 2013, 08:57 PM »
So I've been looking through my list of mods, and multiquote seems to come up fairly often as a request.
Now before anyone says 'but SMF/Wedge already has this', the answer is 'not really'.
OK, so yes, you can click on a post and have it be pushed to the quick reply. That's fine if quick reply is on and you only want to quote one message. In the first case, that's not really an option because it just redirects you to the full reply, in the second it's awkward - the first time you click, it sends the content to the quick reply, but then pushes you down to the quick reply.
Which brings me to conventional multiquote. The idea is that you click on multiple messages, and it adds them to a list - including across pages of a topic if desired. Then you click on a main button and all of the messages are quoted at once in the post, with appropriate quote tags.
So, how important is this? How often would it be used? Is it worth our time to investigate? I'm mostly inclined to argue that our current implementation is probably 'good enough' but I'm not normally satisfied with things that are merely 'good enough'.
Now before anyone says 'but SMF/Wedge already has this', the answer is 'not really'.
OK, so yes, you can click on a post and have it be pushed to the quick reply. That's fine if quick reply is on and you only want to quote one message. In the first case, that's not really an option because it just redirects you to the full reply, in the second it's awkward - the first time you click, it sends the content to the quick reply, but then pushes you down to the quick reply.
Which brings me to conventional multiquote. The idea is that you click on multiple messages, and it adds them to a list - including across pages of a topic if desired. Then you click on a main button and all of the messages are quoted at once in the post, with appropriate quote tags.
So, how important is this? How often would it be used? Is it worth our time to investigate? I'm mostly inclined to argue that our current implementation is probably 'good enough' but I'm not normally satisfied with things that are merely 'good enough'.
1577
Plugins / Re: Custom form (ideas, discussion)
« on February 16th, 2013, 08:52 PM »
I see no reason why you'd need a plugin to create those, though. If the out-of-the-box setup is flexible enough you could create all of those anyway (a la profile fields)
But yeah, I'd create plugin facilities anyway.
But yeah, I'd create plugin facilities anyway.
1578
Bug reports / Re: Mini-menu implementation
« on February 16th, 2013, 07:11 PM »- By order of optimization importance: index template HTML, script.js, any other JS file. I'd suggest looking into providing the bare necessary, such as <div id="searchx" data-tid=topicID data-bid=boardID></div>, and then using a cached JS block to suggest a search destination. (Isn't it a good thing that $txt can be cached too by now? :P)
- Mobile is something I strive to look into, but it's not my absolute priority. I did fix something related to this today though, I added 13 bytes of JS to disable username clicks on Android if they're associated with a mini-menu. Fair trade. (..............And here's me thinking about adding browser name/version to JS filenames :lol:)
Anyway, all I can say is, mobiles need a visual clue for a menu, so I guess it's best to show one of the '+' icons and just have the menu show up when hovering these...
- Can't use one delay in a page and no delay in another...
1579
Bug reports / Re: Mini-menu implementation
« on February 16th, 2013, 06:28 PM »Good then.
I know that this feature rewrite doesn't excite anyone right now (and me even less), but for anyone who's been using the thoughts feature, especially on the homepage, this will have an influence on your perceived enjoyment of it...
I could either reduce the delay to 50ms or so, or completely remove the code and assume that mini-menus will always be applied only to a limited portion of hoverable content.
1580
Plugins / Re: Custom form (ideas, discussion)
« on February 16th, 2013, 03:07 PM »
What kind of field could you add, exactly?
Conceptually I can see it happening, I'm just not entirely sure what you would want to add.
Conceptually I can see it happening, I'm just not entirely sure what you would want to add.
1581
Bug reports / Re: Mini-menu implementation
« on February 16th, 2013, 03:05 PM »
Well... I only put the sortable in a side page that isn't likely to be used that often anyway (it's not a regular member page, but a staff member, it's only just above the admin panel really)
But the area I'm talking about is an admin area. ;)
But the area I'm talking about is an admin area. ;)
1582
Bug reports / Re: Mini-menu implementation
« on February 15th, 2013, 11:15 PM »
I know the feeling.
The stuff I have is not commit-ready and I refuse to commit it in the state it's in because it just doesn't work properly, before I even get into the performance issues I can see that might occur.[1]
End of the day the only real judge is yourself.
The stuff I have is not commit-ready and I refuse to commit it in the state it's in because it just doesn't work properly, before I even get into the performance issues I can see that might occur.[1]
End of the day the only real judge is yourself.
| 1. | All I can say is that the table in question is heavily used and more than one SMF/Wedge bug has been because of its reliance on MyISAM ordering. And that combining that with this you might realise what I've been doing today. |
1583
Bug reports / Re: Mini-menu implementation
« on February 15th, 2013, 11:10 PM »
It's OK, I'm not happy with any of the stuff I've done today either. I've been experimenting :whistle: but nothing I want to share yet.
1584
Plugins / Re: Custom form (ideas, discussion)
« on February 15th, 2013, 07:29 PM »
That's why it's in the plugins area ;)
Yes, it is something that is needed. But it certainly isn't needed in the core from my perspective.
Yes, it is something that is needed. But it certainly isn't needed in the core from my perspective.
1585
Plugins / Re: Custom form (ideas, discussion)
« on February 15th, 2013, 07:02 PM »
I see that as a very small part of the functionality ;)
The *real* trick will be tying things to helpdesk custom fields. But I'll see what I can do when I get there. This is still very much an 'idea' right now.
The *real* trick will be tying things to helpdesk custom fields. But I'll see what I can do when I get there. This is still very much an 'idea' right now.
1586
Plugins / Re: Custom form (ideas, discussion)
« on February 15th, 2013, 06:02 PM »
Would it not be easier to simply allow 'posting to a helpdesk ticket' as a possible target for the form?
1587
Plugins / Custom form (ideas, discussion)
« on February 15th, 2013, 05:23 PM »
So I'm in a fractious mood and can't settle on anything. Time for some ideas then.
The notion of needing custom forms is nothing new. Different sites have them for different purposes. Then we have the contact form plugin that already exists, and I figured I could solve both issues at once.
So here's the thought I'm having: a system that allows admins to build forms in their site with the following:
* permissions of who can see the form
* what should happen when the form is submitted (any/all of the following, would be configurable)
- create a new topic in a given board
- send emails to people
- send PMs to people
* allow creating forms out of modular units, i.e. the different things we might want in forms (textboxes, bbcboxes, numbers, select boxes etc etc)
* optional whether the CAPTCHA is required
* optionally adding them to the menu somewhere
* optionally creating an action for them for easy linking[1]
Thoughts? Does it seem like it needs anything else? Of course it would have all the usual Arantoric refinements. :eheh:
The notion of needing custom forms is nothing new. Different sites have them for different purposes. Then we have the contact form plugin that already exists, and I figured I could solve both issues at once.
So here's the thought I'm having: a system that allows admins to build forms in their site with the following:
* permissions of who can see the form
* what should happen when the form is submitted (any/all of the following, would be configurable)
- create a new topic in a given board
- send emails to people
- send PMs to people
* allow creating forms out of modular units, i.e. the different things we might want in forms (textboxes, bbcboxes, numbers, select boxes etc etc)
* optional whether the CAPTCHA is required
* optionally adding them to the menu somewhere
* optionally creating an action for them for easy linking[1]
Thoughts? Does it seem like it needs anything else? Of course it would have all the usual Arantoric refinements. :eheh:
| 1. | And SEO if that floats your boat |
1588
Features / Re: Bye Bye Recycle Bin?
« on February 15th, 2013, 04:58 PM »
Nope. The performance concern is still ultimately there. It is really not a significant change on top of what's already in place for post moderation.
It's mostly avoidable by tracking in a given topic whether or not there are deleted or moderated (currently moderated posts are recorded), which means it's possible to not add the extra conditions in Display if you know you don't need to check for them.
Of course, it's entirely possible that I'm just overcautious...
It's mostly avoidable by tracking in a given topic whether or not there are deleted or moderated (currently moderated posts are recorded), which means it's possible to not add the extra conditions in Display if you know you don't need to check for them.
Of course, it's entirely possible that I'm just overcautious...
1589
Off-topic / Re: Strange behavior of jap chars on title="" tooltip
« on February 15th, 2013, 04:48 PM »
It's nothing to do with the font for the page. You as a web developer have precisely zero control over what Windows does with tooltips.
Windows 7 makes it almost deliberately awkward to find it, too. What's curious is that Windows 7 itself uses Segoe UI by default. Earlier versions of Windows used different fonts (usually Tahoma if memory serves) which very firmly had troubles, but it would seem that something changed in Win Vista+.
Related thing I found: https://code.google.com/p/chromium/issues/detail?id=102449
Windows 7 makes it almost deliberately awkward to find it, too. What's curious is that Windows 7 itself uses Segoe UI by default. Earlier versions of Windows used different fonts (usually Tahoma if memory serves) which very firmly had troubles, but it would seem that something changed in Win Vista+.
Related thing I found: https://code.google.com/p/chromium/issues/detail?id=102449
1590
Off-topic / Re: Strange behavior of jap chars on title="" tooltip
« on February 15th, 2013, 04:33 PM »
No, it's not an encoding problem. It simply means that those characters are not available in the font Windows is using for tooltips. There's no way around it without rolling your own tooltips in HTML.